Orchestrating File Processing and Archiving Using appRules File Iteration Activities

A common requirement in IT shops is the ability to quickly process lots of files in a manageable and predictable manner.  CSV, Excel, Access, XML, JSON are some of the file types that you may be asked to process and archive.

We recently provided a project snippet to a customer that was migrating hundreds of Excel and Access files from multiple locations into a centralized MySQL database.   In this post, we will use this opportunity to discuss the project snippet and the file iteration activities in appRules.

A majority of the activities that were used in the snippet come from the appRules File System module which is shown below:

In a future post, we will discuss the activities in the appRules File System module as a group.  Note that in addition to the included activities, file and directory functions can also be performed using custom functions.  For this walkthrough, we will concentrate on the activities that were used in the project snippet.

 

Below is the project snippet:

Below is the description of the main activities used in the project to perform the iteration of the files:

  1. DisplayName: InitializeFileInfoSource

Workflow Activity: DirectoryInitializeFileInfoSource

Description: The DirectoryInitializeFileInfoSource activity creates records for each file in a folder.  The records contain information for each file and the file attributes are treated as data field values as shown below.  This feature allows you to treat the file just like other records in appRules.  In this example, the DirectoryInitializeFileInfoSource is the Source and upon initialization, it loads the first record.

Below are the properties of the DirectoryInitializeFileInfoSource activity.

Once configured, the record data fields can be accessed as shown below:

  1. DisplayName: Archive File

Workflow Activity: FileMove

Description: The FileMove activity is used for moving a file from one location to another.

MoveFrom: Instead of specifying a specific file path in this property, the value used in this case is a DataFieldValue from the current file record.

MoveTo: This is the destination for the file.  The file can be move to a specific file path or to a folder as specified.

  1. DisplayName: GetNextFileInfoRecord

Workflow Activity: DirectoryGetNextFileInfoRecord

Description: This activity gets the next file info record which contains the attributes of the specific file.  When the end of the records is reached, App.Result is set to false and iteration will end.

 

Conclusion:   

The appRules File System module includes workflow activities that can be used to iterate files for large file processing projects.  In this example, by using just three activities, we are able to iterate and archive the files without writing code.

 

To download appRules: www.appstrategy.com/appRulesTrial

Using appRules® to Implement Round Robin Lead and Incident Assignments in Dynamics CRM

Assigning leads and incidents to users using a formula that works for your company is a common requirement for most sales, marketing and customer service departments.

While most CRM and customer service solutions provide a rudimentary implementation of lead and incident assignment, they do not offer support for the advanced schemes that most companies require.

appRules includes several workflow activities that can be used to implement a variety of advanced assignment schemes.  In this post, we will explore how you can implement round robin lead assignments in Microsoft Dynamics CRM without writing code.

Using the basic workflow activities in appRules, the project below shows how you can implement a round robin lead assignment solution for Dynamics CRM.

 

Initialization

The activities below are executed once to initialize the sources and targets used in the project.

# Activity Description
1 PreloadDynamicsCRMUsers This activity is the InitializeDynamicsCrmSource activity configured to load selected records from the SystemUser entity.
2 LeadSource This activity is the InitializeDynamicsCrmSource activity configured to fetch selected records from the Lead entity one at a time.  These are the records to be assigned in a round robin fashion.
3 LeadTarget This activity is the InitializeDynamicsCrmTarget activity configured for updating records in the Lead entity.

 

 

Record Iteration

The activities below are executed in a loop to assign the leads in a round robin fashion.  (Looping is implemented using the While activity with a simple App.Result condition.)

# Activity Description
1 AssignLead This activity is the Assign activity configured to assign the lead to the preloaded User.
2 GetNextUserFromList This activity is the GetNextPreloadedDynamicsCrmRecord configured to get the next User record from PreloadDynamicsCrmUsers.

Note: The EndOfListAction property is set to RestartList.  This is what implements the round robin scheme since it will continue cycling through the preloaded users.

3 GetNextLeadRecord This activity is the GetNextDynamicsCrmRecord configured to get the next lead record.

 

By configuring only six out-of-the-box activities, we are able to compose a solution for implementing round robin lead assignment for Microsoft Dynamics CRM.  This solution can be run on premise or in the cloud.

You can download this project at: http://www.appstrategy.com/appRulesTrial

Business Rules 101: appRules Decision Tables for Beginners

In this Business Rules 101 post, we will take a very quick look at Decision Tables in appRules.  Decision Tables are an important part of any business rules engine.  And they play an important role in appRules business rules projects.  At a future date, we will do a Deep Dive post on appRules Decision Tables.

If you have not checked out our earlier Business Rules 101 post on Configuring Actions and Conditions, you should do so before continuing.  The Actions and Conditions post can be found at: https://blog.appstrategy.com/2016/06/24/business-rules-101-configuring-actions-and-conditions-in-apprules/

Once you understand the basics of appRules Actions and Conditions and how to configure them, you’re ready to start composing business rules projects that contain decision tables.

But first; What is a Decision Table?

For now, Wikipedia will do:

Decision tables are a precise yet compact way to model complex rule sets and their corresponding actions.

Decision tables, like flowchartsif-then-else, and switch-case statements, associate conditions with actions to perform, but in many cases do so in a more elegant way.

 

Let’s get started!

From the appRules Business Rules module, drag the EvaluateDecisionTable activity on to the designer.

The blank Decision Table Editor window will be displayed:

To configure the decision table, right mouse click on the table to display the context menu.  It is through the context menu that you perform all actions on the decision table.  And, the appRules Decision Table context menu is really a context menu in every sense of the word.  The number and type of entries on the menu changes depending on where you clicked on the table.  Follow the on-screen instructions to configure the table entries.

Below is a view of the decision table context menu:

As noted earlier, the entries visible on the context menu depend on where you clicked on the table.  We will cover some of the key menu items when we do the Deep Dive post on appRules Decision Tables.

 

Note: When adding Decision Table Actions and Conditions, the method is the same as when adding Actions and Conditions directly from the Toolbox.

 

Below is a sample decision table containing conditions and actions for applying discounts to customer orders:

At any time, you can validate and do a test run of the decision table.  appRules prompts for test values and displays the result.  Decision tables can be combined with other business rules and data integration activities to compose very powerful solutions.

 

Conclusion

The appRules business rules and integration engine fully supports the development of powerful projects without using decision tables.  But for complex decision making solutions, the addition of appRules Decision Tables adds precise yet compact way to model complex rule sets and their corresponding actions.  And it is done mostly without writing code.

 

You can download appRules with sample business rules projects at: http://www.appstrategy.com/appRulesTrial

Managing and Synchronizing Parent/Child Workflows in appRules®

Time to share more implementation tips and tricks. This time, we will share ideas on how th manage and synchronize jobs instantiated by a parent job.

 

You can launch child workfows from any running workflow in appRules in the following ways:

  1. Custom Function

You can use the App.ExecuteWorkflow() method in a custom function to launch a child workflow.

 

  1. ExecuteWorkflow Activity

You can add and configure an ExecuteWork activity anywhere in your workflow to launch a child workflow

 

  1. SplitFile Activity

When a SplitFile workflow activity is used to split a file, it can also launch a child workflow to process the records in the files.

 

  1. WatchFileSystem Activity

When a WatchFileSystem workflow activity is used to implement a file watcher (file drop) solution, it can also launch a child workflow to process the records in the files.

 

  1. Target DataManager

You can configure the HighPerformance property of some Target activities to process records in batches.  A child workflow can be launched to process records in each batch.

 

 

If the child workflows are launched as separate processes (asynchronous), there is the possibility that they will still be running when the parent workflow is completed.   Depending on the project, it may not be a big deal to have child workflows running while the parent  is no longer running.  But for other projects, there is a need to synchronize the running of the child workflows with the parent workflow.    Depending on the project, you may want to relate the child workflows to the parent, while in other projects, it is not as important to relate child and parent workflows.  Tying child workflows to their parent allows you to easily navigate to them while viewing Project  Run Details.

 

Relating Parent and Child Workflows

When a child workflow is launched, unless it is tied to the parent workflow, it is free to start and run without any link to the parent.  In that case, no parent relationship information is captured and stored for the child workflow.   To related a child workflow to a parent, the parent workflow information must be passed as arguments to the child workflow.  The arguments must be defined as follows in the child workflow:

When a child workflow is launched from a SplitFile activity or from a Target activity, the arguments are automatically passed to the child workflow.  If the ProjectId and ProjectInstanceId of the parent workflow are not included in the argument list, the child workflow will not be launched successfully.

When a child workflow is launched from a custom function or from an  ExecuteWorkflow activity, the arguments must be specified in the parameters list as follows:

Synchronizing Parent and Child Workflows

If for some reason your parent workflow needs to wait for child workflows to complete, you can add a While activity with a condition to implement a check-and-delay loop:

To wait for the child workflows to finish, set the Duration property of the Delay activity to the amount of time you wish to wait before checking again to see if the child jobs are done.

Conclusion

appRules includes several options for managing and synchronizing parent/child processes.  Select the option that works best for you to optimize processing and capture the necessary reporting details.

You can download appRules with sample projects at: http://www.appstrategy.com/appRulesTrial

 

 

Replicate Cloud Platform Data Using the appRules® Data Replication Activity

As companies move applications to the cloud, there is an increasing need to make data available locally for many reasons.  IT organizations want to store the data locally for backup purposes, reporting and data analysis using familiar and latest tools.

appRules includes a very powerful workflow activity that is specifically designed to replicate data in a SQL database.  The ReplicateData activity is available in most modules of appRules.  It is designed to allow you to replicate data by simply configuring properties.   You can elect to to replicate all entities or to replicate only a selected list of entities.

Figure 1 shows a simple but very powerful workflow that can be used to replicate Dynamics CRM data in Microsoft SQL Server.  The process is the same for replicating Salesforce, SugarCRM, NetSuite, Eloqua, HubSpot, Marketo, SAP and other data sources.

Figure 1: ReplicateDynamicsCRMData

Accept the default entity configurations or make changes:

Select Entities:

Configure the properties below and you are ready to go.

Conclusion

The ReplicateData activity is a powerful tool for replicating SaaS data in SQL Databases.   It includes configurable options for managing every aspect of the process.

You can download appRules with sample projects at: http://www.appstrategy.com/appRulesTrial