Creating Jaspersoft Domains from BPM Case Data Models

Understand the ActiveMatrix Business Object Model

To be able to create effective domains from ActiveMatrix BPM case data models, the domain designer needs to have a good understanding of:

• the underlying business object model and how it is used by ActiveMatrix BPM processes.
• how the business object model classes are mapped to case data tables when the model is deployed to the ActiveMatrix BPM runtime.
• the domain's intended or potential reporting use cases.

Use Derived Tables and Joins to Resolve Potentially Ambiguous Relationships in the Data

Domains and Ad Hoc Views/Reports offer an elegant and powerful reporting tool that allows users to quickly create reports using business terms and language, hiding the complexity of the underlying data relationships. However, because you do not have control over the underlying SQL queries generated by Ad Hoc Views/Reports, you must ensure that your domain design deals with any potentially ambiguous relationships in the data. Ambiguous relationships, if executed as part of a report, can result in unexpected or incorrect data being returned. You can do this by:

• creating derived tables to access objects that you cannot otherwise uniquely access via the existing tables.
• carefully managing the joins used by the domain so that object relationships can be uniquely identified and traversed.

For example, the Claim business object model defines the global classes Claimant, Notifier and Witness, which are used by the Claim class, as specializations of the Person class.

When the ClaimModel project is deployed, the Claimant, Notifier and Witness classes are all mapped to the same database table, BDS_2_CLMMDL_PERSON. The DTYPE column in that table identifies whether the Person is a Driver, Claimant, Notifier or Witness, using the notation namespace.className - for example, com.example.claimmodel.Driver. Foreign keys are created representing the claimants, notifier and witnesses relationships in the Claim business object model.

The Claim domain has been created to represent the Claim business object model, using the data from the BDS_2_CLMMDL* tables.

Suppose that you now want to create an Ad Hoc report from the Claim domain that displays a table containing claim IDs (BDS_2_CLMMDL_CLAIM.CLAIMID) and the last name of the person who is the notifier (BDS_2_CLMMDL_PERSON.LASTNAME). Using the JasperReports Server Ad Hoc Editor, when you add the Claim ID field to the view, a preview list of claim IDs is displayed. (You can use the View SQL Query button to see the underlying query that has been executed.)

However, if you now add the Last Name field, the query returns a null data set, instead of the expected list of claimant last names matching these claim IDs.

This happens because:

1. The Claim domain includes three INNER JOINs between the BDS_2_CLMMDL_CLAIM and BDS_2_CLMMDL_PERSON tables, one for each of the foreign keys that represent the claimants, notifier and witnesses relationships in the Claim business object model.
2. The underlying query generated by the report does not know which of these joins it should use to obtain the LASTNAME from BDS_2_CLMMDL_PERSON. In this particular case, it uses all three, and evaluates the query using AND rather than OR logic. As a person cannot be a claimant, a notifier and a witness, no data is returned. (Again, you can use the View SQL Query button to see the underlying query that has been executed.)

If you have large business object models with complex data relationships, this problem can easily grow exponentially.

To overcome this problem, the Claim domain:

1. Creates derived tables called Driver, Claimant, Notifier and Witness from the BDS_2_CLMMDL_PERSON table. The query uses the DTYPE value, which identifies whether the Person is a Driver, Claimant or Notifier. For example, the query used to generate the Notifier table is:

   select * from amxbpm.BDS_2_CLMMDL_PERSON where DTYPE='com.example.claimmodel.Notifier'

2. Creates explicit joins from each of these tables to the BDS_2_CLMMDL_CLAIM table, representing the claimants, notifier and witnesses relationships in the Claim business object model.

You can now create an Ad Hoc report from the Claim domain that displays a table containing claim IDs (BDS_2_CLMMDL_CLAIM.CLAIMID) and the last name of the notifier (NOTIFIER.LASTNAME). The generated query is able to uniquely identify the join that it needs to follow to resolve the query.

Design Domains on a Use Case Basis

If you are converting a complex business object model you should create domains that are tailored to specific reporting use cases. Creating multiple domains from the same business object model for different use cases is likely to produce better results than attempting to use a single domain that encompasses the entire model. This will avoid problems such as having to map data that is used rarely or not at all in your reports, or exponentially increasing complexity when trying to resolve joins.