Java XOMJava resources

After you have deployed a Java™ XOM as JAR or ZIP resources, you can view these resources in the Rule Execution Server console.
From the Resource View, you can:
  • Deploy new Java XOM JAR or ZIP resources and increment the major version or minor version of the resource.
  • Remove a previously deployed JAR or ZIP resource. Execution units (XU) are notified of the removal, which is logged as a message in the console.
Attention: When the value of the Checksum section of a resource is empty, it means that the resource file is empty. Using the empty resource file can corrupt the database.

The list of rulesets and the list of libraries that use the resource are displayed in dedicated sections. The section dedicated to references from rulesets displays the list of the rulesets that, directly or indirectly, use the resource in the ruleset.managedxom.urisruleset property. The ruleset.managedxom.uris ruleset property allocates the resources to the ruleset at run time.

You can view invalid and unused resources so that you can clean up the resources archive. The Resources Clean-up View contains information that can help you correct the invalid references or remove the invalid or unused resources. Resources are diagnosed as invalid based on the algorithm supported by the res-diagnose-xom-uri Ant task.

Each deployed JAR or ZIP resource has a status:

Valid and in use
  • The data from the URI can be read.
  • The checksum that is stored in the persistence layer is the same as the checksum that is computed from that data.
  • At least one ruleset uses the resource. A ruleset can use the resource transitively through a library that might depend on another library.
Valid and not in use
  • The data from the URI can be read.
  • The checksum that is stored in the persistence layer is the same as the checksum that is computed from that data.
  • The resource is never used in any ruleset, even transitively through interdependent libraries.
Invalid
  • The data from the URI cannot be read.
  • The checksum that is stored in the persistence layer is not the same as the checksum that is computed from that data.