In many architectures, rule applications are authored in one or more development environments. Once a rule application has been tested and has met all of the requirements of a production application, the rule application can be promoted to the production environment one of several different ways.
The design of the rule application promotion workflow is typically championed by the technical users and is predominantly driven from architectural considerations such as the number of irCatalog databases or named environments that will serve the solution.
Each revision of the rule application that is checked into the Catalog increments the revision number for that application. The save date and time are also stored for the revision being checked in. Optionally, new or existing text labels can be assigned to a revision (e.g. Production, DEV, etc).
Single irCatalog Architecture
In a single irCatalog environment, labels are used to identify which rule application revision to access in the integration code. The InRule API classes that are used when calling the rule engine specify a revision label. For example, the production application would only ever want to access the one revision that had the production label. Therefore in a single irCatalog environment, multiple applications can use different revisions of the same Rule Application all saved into the same irCatalog environment. Promotion is achieved each time a utilized label is assigned to a revision of a Rule Application.
Revision Numbers and Multiple irCatalog Architectures
As an alternative to using labels to identify a specific revision of a rule application in code, the InRule API classes we mentioned above can also specify a revision number. Specifying a latest revision number might be most useful in an architecture with multiple irCatalog environments. For example, rule applications can be promoted from one irCatalog environment to another. Rule applications could be developed and tested in a staging environment and once a rule application has met the requirements for production, the revision could be promoted to the production environment.
Integration code that is pointed at the production environment could be configured to only access the latest revision in that environment. To promote a rule application across irCatalog environment, access the irCatalog Manager Website pointing to the irCatalog environment from which you wish to promote.
Find the desired rule application in the rule applications module, and then drill into the individual rule application by clicking on the rule application name link. From there, find the specific revision for promotion and click on the revision number link. Click the "Promote" button.
Enter the required information and click "Promote".
Catalog URI: URI of the target irCatalog environment. If you do not see the irCatalog URI in the drop down, click the link "Don't see your catalog? Add it here."
Username: Username for the target irCatalog environment
Password: Password for the target irCatalog environment
Rule Application Name: Optionally rename the rule application being promoted to the target irCatalog environment
Comment: Optionally update default comments for the revision to be inserted into the target irCatalog environment
When a revision is promoted, the changes to the rule application are deployed seamlessly to the application utilizing it. In other words, InRule does not require that you restart the application process or the irCatalog service in order to make the new changes take affect. This is the default behavior, but can be overridden using the refresh interval setting, as explained in "Managing the rule application Cache" section of the Developer Help guide.