I want to know what do you mean by .ADB deployment and what's the benefit of this compare to other deployments and how we can achieve this?
Generate a POJO deployment. Look at the build.bat. The last line shows you how to precompile a project. Advantage
SOG wrote:I want to know what do you mean by .ADB deployment and what's the benefit of this compare to other deployments and how we can achieve this?
of an .adb after 6.8 is, ease of moving the project from one environment to another.
Benefit: Excecution wise it will be faster when you use an ADB file.
When to use an adb file : When your rule project doesn't have an RMA
Why would having an RMA dissuade you from compiling your project into an .adb?
This could be of your help.
Deploying the ruleservice as an ADB has few advantages over repository deployment:
1. Movement of your rules is easier from one environment to other. Like test env to Prod env.
2. With deployment manager, if used (recommended), you do not have to restart the deployment environment (server)
3. When ADB is changed, transaction management is handled automatically.
For generating the ADB, follow the Rule Service generation wizard of BA.
You can use deployment manager and hot deploy with a source repository as well, there is no difference. Also, you can use ADB files and RMA at the same time - just need to implement an (automated) script that compiles and deploys new ADB after making changes in the RMA.
Here are the benefits:
- ADB file is easier to load by the rules server since there is no need to compile it. The execution time for rules will be the same by the rules reloading time and required resources are greatly reduced with ADBs.
- Since it is precompiled upfront, all possible compilation errors will be reported and will have to be addressed at this step. Without it there may be a risk that the latest rule changes break the project and you will get a runtime error from the rules server right in production. Note: the server will not crash even with the source repository, it will simply refuse to load the latest rule changes and will continue to use the previous version. But if you restart rule server at this point it won't start up correctly as it will not have a good copy of rules to load anymore. So ADB makes the deployment process less error-prone.
- ADB file is a binary format that you can't reverse engineer to see what rules are inside. That makes it more suitable if you need to give your rules to a 3rd party or in other situations when you don't want to let somebody see how business logic is defined. Also, it protects you from somebody tampering with the source rules right in production.
- ADB file allows to move all rule changes from one environment as a single file, so you guarantee that either all changes are deployed or none. That makes some IT organizations happier from the change management perspective.
Some of these benefits can be used even with the source repository because you can configure deployment manager to generate and cache ADB files right in the deployment environment. So you still have a source repository in it, but ADB file is used as an intermediate step to avoid compiling rules on next server startups and to ensure that the rule server still has an access to a valid rules project even if you break the repository.
Thanks for that informative reply. I have a question related to the adb size and execution mode. Does changing the execution mode of rulesets from Sequential to either Default or Optimized Inference increase the size of the ADB? Having the single adb file is very beneficial for deployments, except when the adb file reaches 40MB and has to go to several servers.
Thanks for the elaborated details on the ADB file usage and advantages.
Thanks & Regards,
Retrieving data ...