Before jumping in to start composing and orchestrating your projects with appRules, it is recommended that you review this section to get a basic idea of the concepts that drive appRules.
The concepts are not discussed in detail here but are rather presented in a concise manner to help you hit the ground running. In addition to understanding the concepts and features, this section will also introduce you to the most frequently used terms in appRules.
While appRules features so many options, only the key common features are included in this section.
The actual work performed by appRules projects are done through the execution of one or more workflow activities.
A workflow activity takes input and gives output and contains user-configurable variables and properties. appRules workflow activities are grouped into modules that can be configured to complete a process. appRules activities are able to move and share data between modules and also with external systems.
Each module is specific to the features of the application that it supports -- including files, databases, SAAS etc.
The process of composing your projects (workflows), involves dragging activities on to the designer, configuring the associated properties, and associating them in a logical sequence order.
appRules is based on appStrategy’s appConnector technology. appConnector technology delivers software libraries that connect a wide variety of applications and data sources.
appConnector functionality is based on workflow activities that are packaged in modules related to the job they perform as a group.
appConnector modules are self-contained and feature their own user guides.
To use a module, refer to its User Guide.
The appRules Business Rules module features powerful workflow activities that are used for configuring Actions and Conditions. In addition, the Business Rules Module also supports the configuration of powerful Decision Tables, Rule Sets and other objects.
In appRules, projects are composed and orchestrated as opposed to being programmed or developed. Using appConnector modules with powerful activities featuring easy-to-use and reusable editors makes this possible.
Compose Projects by dragging and dropping activities from the toolbox into the designer and associate them in sequence using control flow activities (while, if, sequence …):
Business rules, integration and automation jobs can be developed, scheduled and run from the development machine and it is very easy to setup, run and administer.
appRules Portal offers a centralized location for running jobs in an automated fashion. appRules includes a web service interface that allows you to activate projects from other solutions or stored procedures. appRules has administration and maintenance functionalities. All settings for deployments, data sources, and definitions for managing the day-to-day running of the system can be defined.
When you install appRules, it also automatically installs a Setup database - Setup.sdf. The Setup database is a SQL Server Compact Edition database. You will not have to do anything special with the Setup database. But you need to know that it exists and holds general configuration information for your appRules installation. The configuration information includes licenses and other general system-specific settings.
This database is linked to the current product installation and licence, so do not move it to another machine (the sdf file is in the PortalData\appStrategy\Default\Setup folder)
When you install appRules, it also automatically installs a Master database - Master.sdf. The Master database is a SQL Server Compact Edition database. This Database is accessible from the Admin Master option of the File Menu and requires an admin access.
An Admin logged to it can change global settings for the same appRules Portal installation:
Project Databases Management
Product License management
appRules Services Management (WebApi, Scheduler)
appRules stores projects in project databases. Your project database can contain a few, or unlimited number of projects. You can also maintain several project databases and synchronize data between project databases. This feature makes it easy for you to maintain separate environments for Development, Test and Production. Project databases are not just used for storing your job definitions. They also store other data including data source definitions, lists, settings and logs. appRules currently allows you to store your project data in Microsoft SQL Server Compact Edition - (CE) or enterprise SQL Databases (Microsoft SQL Server, MySQL, PostgreSQL). SQL Server CE is used mostly for development and for small and medium deployments. Since it is an embeddable database, it requires little or no resources to create and maintain -- and it is free! The samples supplied with appRules are in SQL Server Compact Edition format. appRules includes utilities (checkin/checkout) that allow you to move your project database from one format to another. For enterprise installations where high performance is required for processing millions of transactions, an enterprise database engine is recommended.
A project database named Samples is installed along with your edition of the appRules software product.
The Samples database contains several examples that show you how to hit the ground running with appRules. In the Community Edition, the main database is named Community.sdf and allows only one project with unlimited features.
In the community edition, the samples database projects can be run but are limited to process up to 250 records. In addition, a database named Northwind containing test data is also installed on your computer.
Using the Northwind test database, you can run the Northwind sample projects in the Samples project database. This is because both the Samples project database and the Northwind databases are SQL Server Compact Edition databases.
You will not be required to configure connection strings for the Samples database and the Northwind database.
They are automatically configured for you so you can run the Northwind sample projects.
And there is no need to install the SQL Server CE software -- it is automatically included in appRules. Before running other sample projects (non-Northwind samples), make sure that you properly configure the required settings (connection strings, authentication etc.).
Most software projects consume a lot of time at runtime (configuring registry settings, checking activations, connection strings, file locations, etc.). To alleviate these problems, appRules includes Runtime Settings that you can use to define how your projects will be deployed -- even before the projects are composed. For example, you can create runtime settings for Development, Test and Production. You can also create runtime settings for locations where the projects will be deployed. There is no limit to the number of runtime settings that you can define. Based on the runtime settings, the projects that you compose will ‘know’ exactly how to behave and the settings to use for connection strings, URLs, file locations etc. To continue with our Development/Test/Production example, while you are developing the project, your project will automatically use the Runtime settings associated to the current user.
The metadata of the data sources to be used in your projects are loaded and maintained in the project database. You can connect once to the data source to create the metadata. After that, you can utilize the project database to work in environments that do not have direct access to the data source.
When creating a data source, appRules gathers not only information related to entities or table metadata, but also any additional information included in the database of applications including pick lists and data mapping information. For example, when creating data source metadata for Microsoft Dynamics CRM and Salesforce.com, pick list information is automatically included so that you can quickly utilize them in your projects (below is an example of DynamicsCrmOnline datasource definition)
To deliver a code-free environment where projects can be created and deployed quickly, appRules employs “Sourced Values”. In simple terms, a Sourced Value allows you to quickly select a source for a value and an identifier for it. To specify a sourced value, you select the Source and then specify a value identifier (Source Value Identifier). Below are some examples of the many sourced values used in appRules:
The Constant source allows you to enter any value in the value identifier. Example: “Constant:John Smith”
The DataFieldValue source gets a value from a record that exists in a specific Source or Target in the project. Example: “Employees.LastName” gets the value of the LastName column in the Employees record.
The DateTime sourced value points to a date/time related value. They can also be used to specify other date/time related data. Example: “DateTime.DateTimeNow” generates the current date/time.
The CustomFunction source allows you to select a function that you have defined in Visual Studio to set a value or perform additional processing (as Conditions)
The above examples give you an idea of how Sourced Values are defined and used in appRules. There are around forty (40) Sourced Value types that you can use to specify data anywhere in your projects.
By providing a rich set of editors and controls to manage Sourced Values, appRules is able to provide a very powerful and flexible combination that gives users the fastest and most compact environment for configuring activities, actions, conditions, and orchestrating processes.
Sourced Values in Property Grid
Below are examples of Sourced Value controls on the property grid at design time:
Sourced Values in Mapping
The example below shows Sourced Values in use for mapping. In this case the values are coming from DataFieldValue, CustomFunction, Concatenation…:
Simple Scripts can be defined in the appRules environment to extend the functionality of the project. The Scripts are stored in the project database. Scripts can be entered, validated and saved using the simple appRules Script Editor. Programming experience is not required. Once defined, the scripts are automatically validated and saved in the project database. The scripts can use the App objects methods (see 2.5.20) to read, write, transform or test the data and variables used in the current project.
Simple and complex functions can be defined using the C# in Visual Studio to extend the functionality of the project at run time. Custom functions can access external .Net methods, appRules methods, variables, arguments and other values in the running process.
The branching, looping and other processing decisions to be made by the processes that you compose will be based on conditions. Activities such as “While”, “If” and others expect conditions as the main property for executing an activity or a sequence of activities if a condition is true or false. appRules includes predefined functions and an Expression Editor that can be used to quickly define simple conditions. Scripts or Custom Functions can be defined to handle more complex conditions. A Script or Custom Function defined for handling a complex condition must return a Boolean value (ConditionFunction or ScriptCondition Sourced Values).
Data Managers are a special set of activities that can be initialized as Sources or Targets in the project. Source Data Managers retrieve data from a data source and make the records and values in them available for other modules in the project. Target Data Managers are used for saving records to a specific data source. The properties, connectors configuration options, and execution context of Data Managers is based on the parent module of the Data Manager.
appRules projects can support an unlimited number of Source and Target Data Managers in the same project. And you can define configuration values using values from unrelated Sources/Targets and even dynamic values. A standard Source can be initialized using an InitializeSource activity and a standard Target activity can be initialized using an InitializeTarget activity.
In addition to standard Data Managers (Source & Target), appRules also supports derived Data Managers such as Lists, Lookups, PreloadedRecords, PickLists, etc.
appRules persists the values of the current records of Data Managers so they can be utilized by other activities using the DataFieldValue Sourced Value. Some appConnector modules provide additional Data Managers that are specific to the data source. Several activity modules for example feature an InitializeSourceFromQuery activity which allows loading of records based on a user-defined query.
appRules includes several options that can be used to optimize the processing of high volume and complex projects. These features are available as configurable properties that are associated with the Targets defined in the project. Some Target activities feature a special property named “BulkLoadOption”. This feature is especially useful when working with SAAS platforms such as Microsoft Dynamics CRM Online, Salesforce.com and others which are notoriously slow due to utilization of web services. By properly configuring the Bulk Load property, your projects will run much faster and can handle much heavier loads.
You can configure your appRules project to log as much information as possible regarding the process. Several selections are included for viewing logs and other project runtime data. After running the job or while it is still running, you can use the Project Run Details window to view all details related to the job, including Activity statistics, Source and Target statistics, performance logs and error logs.
The appRules App object is a subject that belongs in technical discussions. We will not go into a technical deep-dive here but since you are learning about the concepts, features and terminology of appRules, we will give it a cursory look. If you do not have a technical background, it is recommended that you skip this section, since you will be accessing the App object through controls and editors that shield you from the technical details.
The app object is a class that gives you full access to your processes at design time and runtime. In your projects, You can access the methods and properties of the App object directly. The designer will accept conditions directly from the App object.
This allows you to enter expressions to get, set values or conditions expressions in the scripts defined in your projects:
The app object class can also be used in the custom functions defined in Visual Studio (see chapter 3.3)