What is the content of the Product JAR file? I extracted the JAR and found the rules to be in a BIN file, but was unable to read it. Please assist.
When importing a Product JAR file from one environment to another, will re-compilation of the rules occur? Or is the XML simply transferred to the DB? Is any additional validation triggered? I ask this question because we had a scenario where an inappropriate ruleset prerequisite update was made in DEV after a rule was compiled. It worked fine in DEV, but after import to a higher environment, it failed to execute properly due to the ruleset prerequisite issue. Why do prerequisites matter in higher environments? It seems that only runtime should matter.
I appreciate your assistance with these questions.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
While I am looking into the query raised(contents of RAP), could you let me know if you did lock the RuleSet Versions and the application rules to prevent unexpected changes before carrying out the packaging.
The contents of the RAP(Rule-Admin-Product) has the information consists entirely of XML documents in Unicode characters. When you import the RAP into a new environment, only the files are imported. If you import rules in a ruleset that users already can access, the rules may begin executing
immediately. These rules may execute before all the rules in the same archive have been imported.
Similarly, declarative rules begin executing immediately. This means that the declarative processes might fail if the elements or properties they reference have not been uploaded yet. This needs to be planned for when an archive is imported on a system with active users.
From your post, I understand that in the development environment, the prerequisite was updated. So, was the ruleset validation mode changes were done here? If yes, Ruleset validation is performed every time a rule is saved. It guarantees that referenced rules are available on the target system when the ruleset is promoted. Ruleset validation does not affect rule resolution at run time, but is only applied at design time. So, did you observe the issue(while executing the imported rule) at runtime or design time?
The ruleset prerequisite update was made in DEV after compilation of the rule at design time. Therefore, there was no perceived issue in DEV. However, after import to TEST, without performing any save of the rule in TEST, the issue manifested at run time. Given this information, it would seem that re-save of the rule occurred on import of the rules to TEST. Is my hypothesis correct?
While you are awaiting answer to the queries raised from SME, in order to avert similar issue for future, how about once the changes are made in development and found to be working, set the rule to Not Available. This allows you to save a rule without validation. Post import process is completed in another environment, you can change the availability status of the rule. Its just a thought.
I appreciate the idea. It is technically feasible. However, this is a lot of additional overhead to the normal deployment process. It also requires to update the rules in our testing environment, which is against best practice. Therefore, unfortunately, we will not be able to use this approach.
Please let me know when we expect to hear from the SME on my last question.
Your process should probably revalidate and save the ruleset before you lock it and export it. This will catch this type of problem. The import has to save the rules. It is not saving generated code but the rules and then the rules need to be generated in the context of the new environment.