Overview: BOM and execution object model (XOM)
You can build the XOM from different data sources.
The execution object model (XOM) is the model against which you run rules. It references the application objects and data, and is the base implementation of the business object model (BOM). Rule projects reference the XOM.
Through the XOM, the rule engine can access application objects and methods, which can be Java™ objects, XML data, or data from other sources. At run time, rules that were written against the BOM are run against the XOM.
Every BOM element (business element) must have a corresponding XOM element (execution element). The correspondence between execution elements and business elements does not need to be one-to-one. If a business element originates from an execution element, you do not need to specify an explicit mapping. If a business element does not originate from an execution element, you must specify a BOM-to-XOM mapping.
Some internal rules exist for the implicit BOM-to-XOM mapping when you generate a BOM from a XOM. For example, a BOM class is implicitly mapped to a XOM class of the same name.
Designing a BOM for a Java model
When your data model is in Java, you can generate a BOM directly from this Java Execution Object Model (XOM), see Mapping of a BOM created from a Java XOM. You can use XOM annotations to configure BOM generation, see XOM annotations. If you want to extend the BOM with business classes and methods, you can then map these business elements to XOM elements by using BOM-to-XOM mapping in the BOM Editor. You have two means of specifying BOM-to-XOM mapping: extender mapping or ARL mapping, see Rule language and extender mapping. Business users can then author business rules without having to worry about the underlying data types and platform.
At deployment time, if your application is a Java or web application, then the Java XOM is packaged into the application and there are no specific deployment steps you need to take for the XOM. You package the rules and BOM-to-XOM mapping definition into a ruleset archive, which is then available to your calling application through the rule runtime, Rule Execution Server.
If you do not have a Java or web calling application, either because you want to deploy to a testing server for testing and simulation, or because you want to expose your rules as a Hosted Transparent Decision Service (HTDS), then you must deploy the Java XOM to the Rule Execution Server database.
When you test and simulate rule execution, Decision Runner accesses Rule Execution Server for execution, and Rule Execution Server retrieves the XOM from the database.
When you generate a HTDS, Rule Execution Server retrieves the XOM from the database in the same way (see Downloading a HTDS WSDL file).
Runtime XOM considerations
If you use one or more Java XOMs with your decision service, and plan to use the hosted transparent decision service (HTDS) web application, you must carefully design your XOMs. Your XOMs are used throughout HTDS and subject to introspection and serialization/deserialization:
- Serialization from Java to JSON or XML takes place when you generate sample REST requests or provide SOAP or REST responses.
- Deserialization from JSON or XML to Java takes place when you process SOAP or REST requests.
- Introspection of the model takes place when generating an API descriptor (OpenAPI, WADL or WSDL).
As a consequence, you should respect the standard serialization requirements when you design your XOMs:
- Ensure that your Java classes can be instantiated by the serialization engines. Define parameterless constructors for Java classes, and getters and setters for all the required fields, or use annotations to guide the serialization engines when you create objects from your Java classes.
- Avoid cycles in your model.
- (Recommended) Use annotations to ignore fields and properties that are not useful to your decision service.
- (Optional) Annotate your Java classes and/or methods with Jackson annotations for JSON or JAXB annotations for XML to influence the serialization and deserialization of decision service parameters and the generation of API descriptors.
Designing a BOM for an XML model
When your data model is in XML, you can generate a BOM directly from this Dynamic XOM, see Overview: Dynamic execution object model (XOM) and Built-in simple types. If you want to extend the BOM with business classes and methods, you can then map these business elements to XOM elements by using BOM-to-XOM mapping in the BOM Editor. You specify this mapping with ARL mapping, see Rule language and extender mapping. Business users can then author business rules without having to worry about the underlying data types and platform.
At deployment time, the Dynamic XOM and BOM-to-XOM mapping files are packaged with the rules in the ruleset archive, which is then available to your calling application through the rule runtime, Rule Execution Server.
