I was working with a customer today, and they mentioned that one task that is problematic for them is moving business rules from their test database into the production database. Currently, the business rule is manually created via the Clarify Client in the test instance, and then when its all working, it is then again manually re-entered into the production. Manual re-entry is a point of potential failure. The rule may have been perfect in test, but a simple typo when re-entering it in production can cause havoc.
One solution to this issue is to archive the business rule using ArchiveManager or dataex from the test database, and then use ArchiveManager or dataex to import it into production.
First, I created a new business rule in my test system:
|Rule Name/Description:||New Employee Request|
|Conditions:||Case Type = New Employee|
|Action Title:||Create Subcases|
|Message Type:||Command Line|
|Start Action:||0 minutes|
|Message:||C:\WINDOWS\system32\WINDOW~1\v1.0\powershell.exe C:\work\PowerShell\CreateNewEmployeeSubCases.ps1 “[Object ID]”|
We need a directive file, which tells ArchiveManager exactly what to archive. Here’s an example:
This directive file tells ArchiveManager to archive the business rule. It will also archive out its related start events, cancel events, conditions, and actions.
I save the above text into a file named bizrule.dir
Be sure to edit the WHERE clause so that you’re exporting the business rule that you want.
Export the Business Rule
diet.exe -export businessrule.dat -archive -dir bizrule.dir -expdef
Note: although my screenshot doesn’t show it, you should use the
-expdef option, which will export all fields, including empty strings and NULLs.
Import the business rule into the production database
diet.exe -import businessrule.dat
View the rule in the new database
Using BOLT, I can view that the rule now exists in the target database:
And there it is. I’ve just migrated a business rule from one database to another, without manually re-typing it.