Using and extending MD policy enforcement samples
This chapter describes the aspects of using the IBM InfoSphere Master Data Management (MDM) Server and IBM Business Process Manager (BPM) to implement business processes around master data. IBM provides the following set of samples on BPM-based data stewardship and policy enforcement process through the IBM Web Membership community:
•MDM Entity Resolution (MDMSER)
•Policy Enforcement (PE)
•Critical Data Change Verification (CDVP)
You can find the process for downloading these samples by searching for installing master data policy enforcement in the IBM InfoSphere MDM Version 10.1 Information Center at:
In this chapter, any references to the term samples refer to the samples provided by IBM through the IWM, unless otherwise explicitly stated. Although the samples are referenced to explain some of the aspects of development, the patterns and mechanism described apply to any business process that was developed around MDM.
Before you import and customize the sample, install and configure the MDM and BPM software. For detailed installation instructions, see the product documentation. Although both MDM and BPM products can be installed on the same physical system, for demonstrating the capabilities of BPM and MDM working together, install these products in a distributed manner on different hardware to achieve optimal performance. This approach is important in a typical production setup where the business critical data is being processed.
This chapter includes the following sections:
8.1 Configuring MDM Standard Edition for messaging
The event handler publishes the event message from the external system to the BPM WebSphere Application Server.
8.1.1 Configuring the event handler
To configure the event handler:
1. Create an InfoSphere MDM Standard Edition server instance. When you create the instance, select the option to use the embedded event manager of the instance. For instructions on how to create an instance, see the IBM InfoSphere MDM Version 10.1 Information Center at:
2. Open a command window and navigate to the scripts directory in the MDM home directory, for example C:IBMInitiateEngine10.1.0scripts.
3. Use the madconfig utility to configure the event handler:
madconfig configure_instance_eventhandler
When you configure the event handler, see Table 8-1 on page 133 as a reference. This table shows the prompts that you see when you run the madconfig utility, and samples of the values for each prompt.
Table 8-1 Configuration utility prompts
|
Prompt
|
Sample value
|
Description
|
|
Enter an existing IBM Initiate Master Data Engine instance name
|
mdsbpmone
|
Type the name of the existing IBM Initiate Master Data Engine instance that you want to configure to use the event handler.
|
|
Enter the IBM Initiate Event Manager JMS connection factory name
|
javax.jms.QueueConnection
Factory |
Type the Java Naming and Directory Interface (JNDI) name of the queue connection factory that you created when you configured the BPM server to deploy the message-driven bean.
|
|
Enter the IBM Initiate Event Manager publishing destination name
|
eventqueue
|
Type the destination queue name, which is how the destination is referred to in an MDM environment. This name can be any string name. The value is used to configure the event notification settings in the MDM workbench. The value should match publish.destination.name in the com.initiate.server.event.cfg configuration file of the MDM Standard Edition instance.
|
|
Enter the IBM Initiate Event Manager publishing destination user
|
admin
|
Type the administrative user ID for the BPM process center.
|
|
Enter the password scheme that you will be using for the IBM Initiate Event Manager publishing destination
|
plain
|
|
|
Enter the plain text password for the IBM Initiate Event Manager publishing destination
|
admin
|
Type the administrative user password for the BPM process center.
|
|
Would you like to add another IBM Initiate Event Manager publishing destination
|
n
|
|
For more information, see Table 2, “Embedded event handler configuration worksheet,” in the Event notification worksheets topic of the IBM InfoSphere MDM Version 10.1 Information Center at:
8.1.2 Event handler settings
After you configure the event handler, the com.initiate.server.event.cfg file has the entries that are shown in Table 8-2. This configuration file is in the conf directory in the MDM server instance. In Table 8-2, the required configuration entries were modified manually to point to the correct Initial Context Factory and the provider URL. The provider URL is the WebSphere Application Server instance where BPM is running, and Context Factory is the WebSphere Application Server default Context Factory.
Table 8-2 Event handler configuration file entries
|
Entry
|
Value
|
Required or Optional
|
|
#publish.environment.initialcontextfactory.key
|
java.naming.factory.initial
|
Required
|
|
#publish.environment.initialcontextfactory.value
|
com.ibm.websphere.naming.
WsnInitialContext Factory |
Required
|
|
#publish.environment.jndiprovider.key
|
java.naming.provider.url
|
Required
|
|
#publish.environment.jndiprovider.value
|
corbaname:iiop:localhost:2809
|
Required
|
|
#publish.environment.key.1
|
java.naming.security.authentication
|
Optional
|
|
#publish.environment.value.1
|
simple
|
Optional
|
|
#publish.environment.key.2
|
java.naming.security.principal
|
Optional
|
|
#publish.environment.value.2
|
cn=Manager,o=IBM,c=US
|
Optional
|
|
#publish.environment.key.3
|
java.naming.security.credentials
|
Optional
|
|
#publish.environment.password.3
|
admin
|
Optional
|
|
#publish.environment.key.4
|
|
Optional
|
|
#publish.environment.value.4
|
|
Optional
|
Table 8-3 Event handler configuration file entries for MQ queues
|
Entry
|
Value
|
|
#publish.environment.initialcontextfactory.key
|
java.naming.factory.initial
|
|
#publish.environment.initialcontextfactory.value
|
com.ibm.mq.jms.context.WMQInitialContextFactory
|
|
#publish.environment.jndiprovider.key
|
java.naming.provider.url
|
|
#publish.environment.jndiprovider.value
|
<hostname:port>/MDMBPMSRVCONCHANNEL
|
8.1.3 Deploying the Event Handler
After the event handler is configured, deploy the event handler to the instance. To deploy the event handler, run the madconfig deploy_instance_eventhandler batch file command. Then, respond to the event handler prompts, which are listed in Table 4.
Table 4 Prompts for the madconfig command
|
Prompt
|
Sample value
|
Description
|
|
Enter an existing Master Data Engine instance name:
|
mdsbpmone
|
Type the name of the existing Master Data Engine instance that you want to configure to use the event handler.
|
|
Enter the directory that contains Event Publisher JAR files:
|
C:Temp
|
Specify the path for the Java archive (JAR) files. The JAR files are used to create the Initial Context Factory and to create the queue connections and sending messages to the Queue. The JAR files are different for WebSphere Application Server and WebSphere MQ. The following JAR files make up the event handler for WebSphere Application Server JMS implementation:
•bootstrap.jar
•com.ibm.ffdc.jar
•com.ibm.hpel.logging.jar
•com.ibm.tx.jta.jar
•com.ibm.tx.util.jar
•com.ibm.ws.admin.core.jar
•com.ibm.ws.bootstrap.jar
•com.ibm.ws.emf.jar
•com.ibm.ws.runtime.jar
•com.ibm.ws.sib.client.thin.jms_8.0.0.jar
•com.ibm.ws.sib.server.jar
•com.ibm.ws.sib.utils.jar
•com.ibm.wsspi.extension.jar
•j2ee.jar org.eclipse.core.runtime_.jar
•org.eclipse.emf.common.jar o
•org.eclipse.emf.commonj.sdo.jar
•org.eclipse.emf.ecore.jar
•org.eclipse.equinox.common_.jar
•org.eclipse.equinox.registry.jar
|
|
(Continued) Enter the directory that contains Event Publisher JAR files:
|
C:Temp
|
The bootstrap.jar and j2ee.jar files are in the <WAS_HOME>/lib folder.
The com.ibm.ws.sib.client.thin.jms_8.0.0.jar file is in the <WAS_HOME>/runtimes folder.
All the other JAR files are in the <BPM_INSTALL_ROOT>/plugins folder (for example, C:BPMV8plugins). The event handler is deployed and initialized by these JAR files. The process is optimized because these JAR files take less time than when given the entire
untimes folder of WebSphere Application Server 8 to deploy.
|
8.1.4 Configuring the hub model
For MDM Standard Edition, to send notifications, configure the hub model to enable event notifications. MDM workbench can be used to configure the hub model to create notifications in the XML format that BPM can use.
To enable event notification on hub model:
1. Select Events.
2. On the Event Notification tab:
a. For the Destination Name, enter a unique name for the destination, for example, eventqueue.
b. For the Publisher Name, enter the JNDI name of the destination queue, for example, jms/eventqueue.
c. In the Publisher Arguments, enter the required arguments to construct the notification message in BPM format. Example 8-1 shows the format that BPM expects for the message.
Example 8-1 BPM format
<eventmsg>
<!-- The process app acronym and event name are required: The snapshot and UCA name are optional -->
<event processApp="[acronym]" snapshot="[snapshot_name]" ucaname="[UCA_name]"> [event_name] </event>
<!--Optional: The name of the queue for the event to run in-->
<queue> [queue name] </queue>
<!--Any parameters the UCA may require--
<parameters>
<parameter>
<key>param1</key>
<value>![CDATA[value1]]</value>
</parameter>
</parameters>
</eventmsg>
The processApp, eventName, and key are mandatory, and other attributes are optional. The arguments should be provided as name-value pairs that are separated by the carat (^) symbol, for example: processApp=PE^eventname=PolicyEnforcementMessage^key=MDMEventMessageIn (Figure 8-1).
Figure 8-1 Configuring the hub model
3. Select only the required events for which notification should be enabled, for example, ENTITY UPDATED.
4. For Message Format, ensure that only BPM is selected.
5. Deploy the hub configuration.
8.1.5 Configuring IBM BPM Express
To enable IBM BPM Express Edition to receive messages from InfoSphere MDM Standard Edition, on BPM:
1. Set the Provider End Point URL of javax.jms.QueueConnectionFactory to bootstrapMessaging:
a. Open the BPM WebSphere Application Server administrative console.
b. Click Resources → JMS → Queue Connection Factories, and select Queue connection factory with the JNDI name of javax.jms.QueueConnectionFactory.
c. Set Target Inbound transport chain to InboundBasicMessaging.
d. Set the Provider Endpoints to BootstrapBasicMessaging.
2. Disable Secure Sockets Layer (SSL) on BPM version 8.0:
a. From the navigation panel, click Security → Global Security → CSIv2 outbound communications → Client Certificate Authentication → Supported and Transport → SSL-Supported.
b. In the WebSphere Application Server administrative console, click Service Integration → Buses.
c. Locate the bus name, for example, PROCSVR.localhostNode06Cell.Bus. Then click Security.
d. Click Allow the use of all defined transport channel chains, and then click Apply and Save.
3. Restart BPM.
8.2 Configuring InfoSphere MDM Advanced Edition for messaging
The BPM samples are packaged with a set of Python scripts that can be used to configure the WebSphere Application Server instances where MDM Advanced Edition and BPM are deployed. The complete script content is shown in at the end of this section.
8.2.1 MDM Advanced Edition configurations
Configuring MDM Advanced edition required creation of Queues, Queue Connection Factory, Alias Destination, and Foreign Bus Connection on the WebSphere Application Server instance on which MDM is deployed. The following steps can be used to complete the configuration:
1. Go to the <MDM_SERVER_INSTALL_HOME>profiles<ProfileName>in folder. In this example, we go to the C:Program Files (x86)IBMWebSphereAppServerprofilesAppSrv03in folder.
2. From a command line, run the MDMBPMSetupApp.py script. In the script, as shown in the following example, substitute the values for your environment:
wsadmin -lang jython -f MDMBPMSetupApp.py <MDMClusterName> <MDMNodeName> <MDMServerName> <MDMSIBusName> <BPMSIBusName> <BPMEventDestinationName> <BPMMessagingEngineName> <BPMSIBEndpointPort>
The following example shows the script with the substituted values:
wsadmin -lang jython -f C:TempMDMBPMSetupApp.py None MDMNode02 server1 MDM.SIB.server1 PROCSVR.BPMNode05Cell.Bus eventqueueDestination.BPMNode05.server1 BPMNode05.server1-PROCSVR.BPMNode05Cell.Bus 7283
8.2.2 Configuring metadata
InfoSphere MDM Advanced Edition can send notification messages in the XML format that BPM can use. You can enable this feature by using metadata that defines the notifications to send to the BPM destination.
The metadata is configured in the BPMNOTIFICATIONTYPE table (Table 8-5).
Table 8-5 BPM notifications
|
Column name
|
Comment
|
|
NOTIF_TYPE
|
The primary key of the notification type that is defined in NOTIFICATIONTYPE table. It is a foreign key to the NOTIFICATIONTYPE table.
|
|
BPM_PROCESS_APP_NAME
|
Acronym of the process application name that is defined in the BPM server.
|
|
BPM_PROCESS_SNAPSHOT_NAME
|
Snapshot name of the process application that is defined in the BPM server.
|
|
BPM_UCA_NAME
|
Name of the undercover agent on the BPM server to which the notification is intended.
|
|
BPM_EVENT_NAME
|
Name of the event as understood by the undercover agent on the BPM server.
|
|
UCA_EVENT_KEY
|
Name of the key to set in the notification message for the parameter value. This key is the XMLElement type variable that is associated with the UCA. If the value is populated, MDM uses mdmNotificationXML as the key.
|
|
BPM_QUEUE_NAME
|
Name of the queue to which the undercover agent is listening.
|
|
DESCRIPTION
|
A short description of the process.
|
|
EXPIRY_DT
|
Expiration date of the BPM notification type, such as the date after which the BPM notification type is not valid.
|
|
LAST_UPDATE_DT
|
The date on which the record was updated last.
|
|
LAST_UPDATE_USER
|
The user ID who modified the record last.
|
Update this table manually by using SQL because the InfoSphere MDM Server does not provide any services to populate this metadata table.
8.2.3 Configuring IBM BPM Express
To enable IBM BPM Express Edition to receive messages from InfoSphere MDM Advanced Edition, complete the following configuration steps on BPM. These steps create foreign bus connection on the IBM WebSphere Application Server instance on which BPM is deployed.
1. Go to the <BPM_SERVER_INSTALL_HOME>profiles<ProfileName>in folder. In this example, we go to the C:IBMBPMv8.0profilesProcCtr02in folder.
2. From a command line, run the BPMSetupApp.py script. In the script, as shown in the following example, substitute the values for your environment:
The usage is wsadmin -user admin -password admin -lang jython -f BPMSetupApp.py <BPMClusterName> <BPMNodeName> <BPMServerName> <BPMSIBusName> <MDMSIBusName> <MDMMessagingEngineName> <MDMSIBEndpointPort> <AdminUserIdOfBPM>
The following example shows the script with the substituted values:
wsadmin -lang jython -f C:TempBPMSetupApp.py None BPMNode05 server1 PROCSVR.BPMNode05Cell.Bus MDM.SIB.server1 MDMNode02.server1-MDM.SIB.server1 7281 admin
8.3 Importing samples
You can import the samples into BPM Process Designer. They can be used to import any IBM BPM process application.
1. Open BPM Process Designer V8.0.
2. Click Import Process application.
3. In the Import Process App dialog box (Figure 8-2):
a. Click Browse.
Figure 8-2 Import a sample application
b. Select the process application file (.twx extension) that you want to import.
c. Click OK.
The process application is listed in Process Designer after is imported (Figure 8-3).
Figure 8-3 Process applications list
4. To open the application, in Process Designer, click Open in Designer link for customization and editing. Figure 8-4 shows the opened application.
Figure 8-4 Opened application
8.4 Configuring process applications
You can implement the business process so that it is configurable. IBM BPM software provides a mechanism to make process applications configurable. A simple and easy mechanism is provided through exposed process values (EPV), which are global variables that are available throughout the process application. As a common practice, you can use this feature for process-level configurations and to define constants such as field labels, service endpoint URLs, and other environment details. To edit the EPVs, open the process application in Process Designer. You can access the EPVs from the Data category in the left pane of Process Designer (Figure 8-5).
Figure 8-5 Editing EPVs
By using the samples that are provided by IBM, you can configure process applications easily in your environment. For more information about configuring the samples, search for developers samples for InfoSphere MDM Server in the IBM InfoSphere MDM version 10.0 Information Center at:
8.5 Integrating BPM in the enterprise
The IBM Business Process Manager server provides open standards to integrate with other components within the enterprise IT environment. The following integration touch points are supported by BPM:
•Web services
•Java integration
•Integration through JMS messaging
BPM also supports easy integration with the SMTP mail server and WebSphere Operational Decision Management (WODM) rules engine.
This section describes the integration techniques and mechanisms that were used in implementing the samples. The samples primarily used the integration features, such as web services, Java, and JMS messaging that are available for immediate use. Because InfoSphere MDM Server Standard and Advanced Editions expose well-designed SOA services and JMS channels, it is common for BPM and MDM to be integrated through these protocols.
8.5.1 Integration patterns used in the samples
The samples that are provided by IBM use web services, Java, and JMS integration to implement the process applications.
MDM Entity Resolution
In the MDM Entity Resolution (MDMSER) process implementation, BPM and MDM Advanced Edition are integrated through JMS messaging and Java. How this integration was implemented is described later in this chapter. After you import this process into BPM Process Designer, you have to configure only the ServiceEndPointURL variable in MDMConfigurations EPV. The process implementation contains prebuilt integration nodes for all the necessary web service invocation.
The following MDM services are used in this process:
•GetAllOperationalCodeTypesByLangId
•GetParty
•GetAllPartySuspects
•ComparativePreviewCollapseMultipleParties
•CollapseMultipleActiveParties
•UnmarkPartiesAsSuspect
•UpdateSuspectStatus
In this process, a generated SOAP client is used to start MDM web services. You can generate the SOAP client and types by using the wsimport command. For information about using the wsimport command, see the official Java documentation at:
You can also generate the SOAP types and client by using IBM Rational® Software Architect. For more information, see the IBM Rational Software Architect Information Center at:
The communication for the InfoSphere MDM Server to BPM happens through JMS messaging. InfoSphere MDM Standard Edition supports configurations to send messages through a JAM implementation that is supported by WebSphere Application Server. These configurations are available for immediate use with InfoSphere MDM Server.
Policy Enforcement
The Policy Enforcement (PE) process implementation sample demonstrates the integration of InfoSphere MDM Standard Edition through JMS messaging and web services. InfoSphere MDM Standard Edition exposes web services through the web services toolkit and ESOA toolkit. In this sample, the services that are exposed through the web services toolkit were used for integration. These services are more generic in nature and are hub model agnostic.
Critical Data Change Verification
The Critical Data Change Verification (CDCV) process implementation sample demonstrates the integration of InfoSphere MDM Standard Edition through JMS messaging and web services. In this sample, the services that are exposed through the ESOA toolkit were used for integration. These services are more hub-specific, and therefore, offer a higher ease of use when handling data. This process also showcases the use of history data services of InfoSphere MDM Standard Edition through Java integration.
8.6 Extending the samples based on a business case
This section describes how to extend and customize the samples. The processes are kept at a generic level so that they apply in general to any process application. You can use BPM Process Designer to achieve the required customization in most of the scenarios. If you are using Java integration or web services, the development of the Java or web services code requires more development environments such as IBM Rational Software Developer or Rational Software Architect.
Most of the process development or process customization for MDM-specific stewardship implementation includes the following tasks among others:
•Adding a field in the UI
•Creating a services integrator node to start an MDM service
•Modifying the display test of a label
•Retrieving more details from MDM server about a particular entity
The following sections describe the different aspects of the defining and customizing processes.
8.6.1 Adding and removing an attribute
Stewardship activities or any human task requires the data to be displayed on the UI. During the process flow, data is retrieved from MDM Standard or Advanced Editions through the exposed services. The retrieved data can be displayed on the UI for review as part of a human task implementation.
The manner in which the data is presented varies depending on the purpose. For example, if you want to view details about an individual or an organization with related details, such as name and address identifiers, the best way is to display it is in a form format. If you want to compare the data of two entity records, such as names or addresses, you can use a tabular view with each column to see the details of a specific entity, with attributes that match each other. Alternatively, if you want to view a collection of entities, you can use a tabular view, where each row of the table shows a record.
Often the data that is displayed for stewardship processes includes MDM entities, such as an individual or organization that consists of numerous attributes. Not all attributes are of importance to a data steward or for a process application. Depending on the goal of the process application, a set of attributes should be presented to the user. This subset of attributes might change over time based on the needs of the implemented business process. It requires implementing a user interface that is a flexible to support such changes.
The same data that is retrieved from InfoSphere MDM Server might have to be displayed in multiple ways, depending on the requirement. Often only a subset of data needs to be shown on the user interface. Therefore, as a good practice, define a coach-specific data model to decouple the format in which the data is received and the format in which to display the data. Additionally, this approach helps to parallel development of a process, the coaches, and independent testing of the coaches with stubbed data.
Adding more attributes
To add more attributes for display:
1. Decide on the set of attributes that is required to be displayed.
This list depends on the goal of business process. The decision drives, for example, the right choice of service invocation and inquiry level for InfoSphere MDM Server Advanced Edition. Based on this decision, you can retrieve details from the InfoSphere MDM Server at the right volume.
2. Modify the data objects that are associated with user interface.
Modify the data objects that are defined within the BPM environment accordingly. This aspect depends on the manner in which the data object is designed in the BPM environment. For example, when data is to be displayed in a tabular view as name-value pairs, the associated data model can be a list of name-value pair objects. Any additional MDM attribute that is required to be displayed requires another name-value pair object to be added to the list.
3. Modify the script node that composes the object.
Displaying the data on the user interface required the data object associated with the use interface to be composed. Modify the script that is associated with the data object to be composed.
4. Modify the user interface.
The need to change the user interface is driven mostly by the design of the user interface. For example, if the user interface is designed as a form view, add the additional attributes to the user interface. Because BPM supports UI customization, use care to ensure that it does not inadvertently introduce regression.
Removing attributes that are currently being displayed follows similar steps. Again, the removal of attributes is driven by the design of the user interface. For a form view, modifying the files alone from the UI is sufficient. If the UI design is a tabular view to display list of objects, modify the manner in which the list object is created to filter the objects that do not need to be displayed. Use care when you remove any attributes from the data object structure that is associated with the user interface because the data object might be used at other places in the process.
To elaborate more on the steps, consider the sample MDM Entity Resolution (MDMSER). Consider the requirement of displaying more details in the party summary view.
1. Identify the data element to be displayed. Display the party line of business (LOB) relations in the user interface. The required attribute of MDM to be displayed in this case is RelatedLobValue. Also, the label for this attribute in the UI should be the value of the MDM Field LobRelationshipValue.
2. Change the data objects. In this case, the data objects already provide support to store details of LOB relations of party entity. If the support is not provided, modify the data object. Create LobRelationshipObj with the required attributes. Alter the PersonObj to contain a list of objects of type LobRelationshipObj.
3. Modify the script that composes the object to display in the UI. To change the scripts:
Figure 8-6 Remediation Service
b. Open the script node named Prepare Summary Object for UI. The script in the node consists of the data object that is displayed in the model (Figure 8-7).
Figure 8-7 Opening the script node
c. Follow the same pattern as other attributes in the script node to set the LOB details. Declare a list variable with the name lobRelationshipsInfo of type SummaryInfoObj. Example 8-2 shows the script to be added.
Example 8-2 Script snippet
contactMethodType = null;
}
//************ New code - Begin **********************/
tw.local.lobRelationshipsInfo = new tw.object.listOf.SummaryInfoObj();
var lobRelationshipsListIndex = 0;
var lobRelationshipsType = null;
for(var i=0; i < tw.local.sourcePersonObj.lobRelationships.listLength ; i++){
if ((tw.local.sourcePersonObj.lobRelationships[i].lobRelationshipValue != null) &&
(tw.local.sourcePersonObj.lobRelationships[i].lobRelationshipValue != ""))
{
lobRelationshipsType = tw.local.sourcePersonObj.lobRelationships[i].lobRelationshipValue;
}
else
{
if(tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i] != null) {
if ((tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i].lobRelationshipValue != null) &&
(tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i].lobRelationshipValue != ""))
{
lobRelationshipsType = tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i].lobRelationshipValue;
}
}
}
if ((lobRelationshipsType != null) && (lobRelationshipsType != ""))
{
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex] = new tw.object.SummaryInfoObj();
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex].attributeLabel = lobRelationshipsType;
if ((tw.local.sourcePersonObj.lobRelationships[i].relatedLobValue != null) && (tw.local.sourcePersonObj.lobRelationships[i].relatedLobValue != ""))
{
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex].sourcePartyAttributeValue = tw.local.sourcePersonObj.lobRelationships[i].relatedLobValue;
}
if(tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i] != null) {
if ((tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i].relatedLobValue != null) && (tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i].relatedLobValue != ""))
{
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex].suspectPartyAttributeValue = tw.local.suspectPersonObjList[tw.local.suspectPartyNum].lobRelationships[i].relatedLobValue;
}
}
lobRelationshipsListIndex = lobRelationshipsListIndex+1;
}
lobRelationshipsType = null;
}
//************ New code - End **********************/
tw.local.suspectActionList = new tw.object.listOf.String();
This script node handles scenarios when the person entity does not have any suspects that are associated with it.
d. Insert the following snippet as indicated.
Example 8-3 Code snippet for person entity with no associated suspects
contactMethodListIndex = contactMethodListIndex+1;
}
}
//************ New code - Start **********************/
tw.local.lobRelationshipsInfo = new tw.object.listOf.SummaryInfoObj();
var lobRelationshipsListIndex = 0;
for(var i=0; i < tw.local.sourcePersonObj.lobRelationships.listLength ; i++){
if ((tw.local.sourcePersonObj.lobRelationships[i].lobRelationshipValue != null) &&
(tw.local.sourcePersonObj.lobRelationships[i].lobRelationshipValue != ""))
{
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex] = new tw.object.SummaryInfoObj();
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex].attributeLabel = tw.local.sourcePersonObj.lobRelationships[i].lobRelationshipValue;
if ((tw.local.sourcePersonObj.lobRelationships[i].relatedLobValue != null) && (tw.local.sourcePersonObj.lobRelationships[i].relatedLobValue != ""))
{
tw.local.lobRelationshipsInfo[lobRelationshipsListIndex].sourcePartyAttributeValue = tw.local.sourcePersonObj.lobRelationships[i].relatedLobValue;
}
lobRelationshipsListIndex = lobRelationshipsListIndex+1;
}
}
//************ New code - End **********************/
tw.local.lobRelationshipsInfo = new tw.object.listOf.SummaryInfoObj();
4. Modify the user interface. Insert a new table in the coach below the “Contact Methods” table control. Here also the table setting follows a similar setting as the other table controls. Associate the new table with the variable lobRelationshipsInfo, which was previously declared.
Figure 8-8 shows the altered coach.
Figure 8-8 Modifying the user interface
After you make the customizations, when the process is run, the additional attributes are available on the user interface. Figure 8-9 shows the modified user interface.
Figure 8-9 Customized user interface
8.6.2 Changing the attribute label
When customizing process applications, often you are required to change the attribute labels depending on the use case that is being implemented. For example, a front-desk process receives data about an individual and completes a registration. This process is common and has applicability in multiple use cases, such as patient registration in a hospital or customer registration in a bank. In these use cases, the type of data that is collected includes attributes such as name, address, phone number, and date of birth. However, in a patient registration system, it is relevant to have the attribute label as “Patient name” rather than “Customer name.” BPM software provides easy ways to accomplish such requirements.
Also, other considerations can exist for localizations, such as displaying locale-specific label text on the user interface. BPM provides a mechanism to manage and accomplish localization requirements.
In some use cases, the display labels must be populated dynamically, and the display text is modeled as text controls rather than label controls. BPM provides an easy-to-use mechanism to accomplish these requirements as well.
Localization resources
A localization resource is a mechanism that is supported by BPM to manage translated label strings and display the label text based on the locale. You can create localization resources within BPM and associate the labels on the user interface. BPM also supports export and import of the localization resource to edit them out side of BPM environment.
Creating localization resources
To create localization resources for the needs of the process application:
Figure 8-10 Using localization resources
2. In the Create New window, select Localization Resource.
3. Enter a valid name for the localization resource, for example CoachLabels, and then click Finish.
The newly created resource is opened for editing (Figure 8-11).
Figure 8-11 Localization Resource
4. In the Localization Resource pane (Figure 8-12):
a. In the Localizations section, click Add to add the required locales.
b. In the Localization Keys section, click Add to add the required keys. The keys that are defined are associated with the labels in the user interface.
Figure 8-12 Define localization keys
5. In the Localization Values section, add the local specific label text for the keys defined.
Associating localization resources with the attribute label
The created localization resources can be associated with the attribute label. The attribute label shows the locale-specific text, depending on the locale in which the process application is run (Figure 8-13).
Figure 8-13 Localization text
To associate the resource key with the label:
1. On the Variables tab, click Link Localization to link the required localization resource.
2. On the Coaches tab, select the attribute that you want to localize.
3. Click the Properties view, and select the Label Visible check box.
4. In the Label text box, specify the key that you want to apply to the Label Control.
By using this mechanism, you can easily manage translated text for the labels and modify the label text. The label is not hardcoded in the process application user interface. Therefore, modifications to the values in the localization resources that are associated with the label are reflected automatically without changing any other artefact.
Exposed process values
You can use EPV variables to provide flexibility to change attribute names. EPVs are useful in scenarios where localization support is not required. They are also useful where attribute names are not designed as label controls and the labels must be populated dynamically. Before you can use an EPV variable, you must define and link it to the UI or service implementations in which it is used.
For more information about EPVs, search for Creating exposed process values (EPVs) in the IBM Business Process Manager, V8.0 Information Center at:
Consider a use case where you have to display a list of values and the label for these values depends on the metadata of the attribute. Most of the times, the metadata is cryptic, and a display label for the attribute might be different. In such cases, using EPVs is convenient. The standard display labels can be defined as EPVs. By using a script, you can create a map between the attributes metadata and the display label to help to display the label dynamically based on the metadata of the attribute. The flexibility of changing the attribute display labels can be achieved easily by chancing the EPV variable.
In scenarios where localization support is required and the display text must be populated dynamically, use a combination of EPVs and localization resources.
In the samples that IBM bundles with the InfoSphere MDM Server, the EPVs are used extensively to define the attribute labels.
EPVs in MDM Entity Resolution
Consider the MDM Entity Resolution (MDMSER) sample in Figure 8-14.
Figure 8-14 Use of EPVs in Entity Resolution
The attribute labels are defined in the EPV named CoachLabels. Consider the FAMILY_NAME variable in this EPV. This EPV variable is used in the user interfaces that are defined in the process. This variable holds the “Family name” value. The label on the user interface is displayed as shown in Figure 8-15.
Figure 8-15 Using the Family name variable
To change the display text to “Last name,” modify the value of EPV variable FAMILY_NAME to Last name as shown in Figure 8-16.
Figure 8-16 Changing the name variable
With this change, all the labels that are bound to this EPV variable automatically show the modified label text (Figure 8-17).
Figure 8-17 Modified label
Another use case where use of EPVs are helpful is when using attribute metadata as an attribute label. In many scenarios, the metadata must be mapped to more human readable text that needs to be displayed as a label.
EPVs in MDM Policy Enforcement
Consider the MDM Policy Enforcement (PE) sample. In this process, EPVs are used to map the metadata to the display text that is used as a label. InfoSphere MDM Server Standard Edition provides data types that can be readily used to construct the member models. (A detailed description about the MDM element types and creation of member models is outside the scope of this book.)
When the member record is retrieved from InfoSphere MDM Server Standard Edition, the member record is returned with the metadata. Typically, a member record contains segments, and each segment contains attributes. Member records can have multiple segments at the same time. For example, LGLNAME (Legal name) and MAIDENNAME (Maiden name) are two segments that are of type MEMNAME in the member record. Further, the MEMNAME type has atomic attributes. For example, “onmFirst” corresponds to “First name.” Even though all the metadata is available with the member record, for human readability “onmFirst” is not suitable. To overcome this issue, the MDM Policy Enforcement process implementation uses EPVs to provide a mapping of segment name and attributes name to human readable display labels.
The EVPs MDSSegmentNames and SegmentNameConfiguaration define the mappings for the segment metadata to the display labels. The EPV MDSSegmentNames defines the segment metadata that is used within the samples (Figure 8-18).
Figure 8-18 Defining mappings for segment metadata
The EPV SegmentNameConfiguaration defines the display names of the segments that are used within the samples. The display name of LGNAME segment is LEGAL NAME (Figure 8-19).
Figure 8-19 Defining the display names
Similarly, the EVPs MDSAttributeNames and AttributeNameConfiguaration define the mappings for the attribute metadata to the display labels. The EPV MDSAttributeNames defines the attribute metadata that is used in the samples, as shown in Figure 8-20.
Figure 8-20 Define the attribute metadata
The EPV AttributeNameConfiguaration defines the display names of the segments that are used in the samples. The display name of the “onmFirst” attribute is “First Name” as shown in Figure 8-21.
Figure 8-21 Define segment display names
These EPVs are used in the script implementation. Open the Retrieve Entity Details service implementation. In the script node, Build Generic Object, the EPVs are used to construct the object to display on the user interface (Example 8-4).
Example 8-4 Construct object to display in the user interface
//Add Name Details
if( tw.local.members[j].memName != null ){
for( var i = 0 ; i < tw.local.members[j].memName.listLength ; i++ ){
var nameSegement = new tw.object.MemberObject();
nameSegement.attributes = new tw.object.Map();
//Add LegalName
if(tw.local.members[j].memName[i].attrCode == String(tw.epv.MDSSegmentNames.LGLNAME)){
nameSegement.attributes.put(String(tw.epv.MDSAttributeNames.onmFirst), tw.local.members[j].memName[i].onmFirst);
nameSegement.attributes.put(String(tw.epv.MDSAttributeNames.onmLast), tw.local.members[j].memName[i].onmLast);
genericMemberData.segments.put(tw.local.members[j].memName[i].attrCode, nameSegement);
//Construct map for DisplayName of each segment and attribute
genericMemberData.segmentNameConfiguaration.put(tw.local.members[j].memName[i].attrCode,String(tw.epv.SegmentNameConfiguaration.LGLNAME));
genericMemberData.attributeNameConfiguaration.put("onmFirstLGLNAME",String(tw.epv.AttributeNameConfiguaration.onmFirst));
genericMemberData.attributeNameConfiguaration.put("onmLastLGLNAME",String(tw.epv.AttributeNameConfiguaration.onmLast));
}
else
//Add Maiden Name
if(tw.local.members[j].memName[i].attrCode == String(tw.epv.MDSSegmentNames.MAIDENNAME)){
nameSegement.attributes.put(String(tw.epv.MDSAttributeNames.onmFirst), tw.local.members[j].memName[i].onmFirst);
nameSegement.attributes.put(String(tw.epv.MDSAttributeNames.onmLast), tw.local.members[j].memName[i].onmLast);
genericMemberData.segments.put(tw.local.members[j].memName[i].attrCode, nameSegement);
//Construct map for DisplayName of each segment and attribute
genericMemberData.segmentNameConfiguaration.put(tw.local.members[j].memName[i].attrCode, String(tw.epv.SegmentNameConfiguaration.MAIDENNAME));
genericMemberData.attributeNameConfiguaration.put("onmFirstMAIDENNAME",String(tw.epv.AttributeNameConfiguaration.onmFirst));
genericMemberData.attributeNameConfiguaration.put("onmLastMAIDENNAME",String(tw.epv.AttributeNameConfiguaration.onmLast));
}
}//for
}//if
Exposed process values can be used as a mechanism to define the display labels, which in turn, you can use to modify easily without requiring any extensive code change.
8.6.3 Adding and changing a policy
Enterprises that implement master data solutions establish data governance policies. A critical aspect of data governance is to ensure that the data that gets into the system adheres to those policies. Data governance must also provide ways to detect any noncompliance of the established policies so that it can be remediated. Enterprises implement these policies in multiple ways depending on the complexity of the policies. One widely used implementation of governance policies is through rules.
IBM BPM comes with a BAL rule component to create rules. This component provides a rule editor that rule designers can use to author business rules by using natural language technology. Using natural language instead of JavaScript to author rules means that no programming expertise is required to create business rules. Also, the rules are easier for people to read and understand.
By using Process Designer, non-developers can express business logic by using BAL in business rules. In most cases, business rules can be fully developed and implemented by using Process Designer. However, in some situations, the business logic might reach levels of complexity that are not supported within IBM Business Process Manager. In this case, the business logic can be exported without modifications to IBM WebSphere Operational Decision Management JRules Rule Studio. The export procedure produces a complete business rules project suitable for continued work within JRules. After the rules are exported, they are imported into Rule Studio, and the rules are deployed on a Rule Execution Server. The business process in Process Designer can use the resulting rule application by using a remote decision service that is provided by JRules.
For more information about BAL rules, search for Adding a BAL Rule component to a service in the IBM Business Process Manager V8.0 Information Center at:
In the samples that IBM bundles with the InfoSphere MDM Server, the BAL rules are user-defined policies through data validation.
BAL rules in MDM Policy Enforcement
The PE sample showcases the use of BAL language for policy implementation. It also used an XML file for textual description of the policies that are wrapped in a Java adapter to retrieve the content of the XML.
To enhance the sample, by defining a new rule for a policy, you can create a Decision service by using Process Designer. For information about creating a Decision service, search for Adding a BAL Rule component to a service in the IBM Business Process Manager V8.0 Information Center at:
In the diagram of the new Decision service that you create, click BAL Rule in the component palette and drag the BAL Rule component icon from the palette to the service diagram. Link any other service implementation in BPM. In the Decision service, you can also map the input and output variables, which can be accessed within the BAL rule language. You can use the pre-execution and post-execution assignments to extract the data element for processing by the BAL rule and construct a data object that represents the result of the rule execution.
The Decision service can then be nested in a General System service and used in the business process. In this sample, the text descriptions for the policy are provided through a simple XML script (Example 8-5).
Example 8-5 Policy descriptions
<?xml version="1.0" encoding="UTF-8"?>
<p:PolicyValidations xmlns:p="http://www.ibm.com/mdm/datagovernance/PolicyValidation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/mdm/datagovernance/PolicyValidation PolicyValidation.xsd ">
<policyValidation>
<policyID>1</policyID>
<policyShortDesc>SSN value cannot be Null</policyShortDesc>
<policyLongDesc>SSN value for the entity record cannot be null</policyLongDesc>
<policyRemediationApproach>Remediation approach</policyRemediationApproach>
</policyValidation>
You can update this XML and the file in the business process application library. Ensure that the policyID is a unique string. The sample provides data object definitions that can hold the details that are provided through XML.
8.6.4 Adding an activity
Activities are the individual business tasks within a process that make up the larger business goal. When you define the business process by using Process Designer, these activities are typically a service implementation. The activities are a set of service implementation types that are supported by BPM. The type of service that you create depends upon the requirements of the activity. For example, if an activity requires integration with an external system, such as a database, you can create an Integration service. If an activity requires that call center personnel enter data about customer requests, you can create a Human service with a coach.
You can choose from the following activities:
Decision service Use when you want a condition to determine the implementation that is started. For example, when a condition evaluates to true, IBM BPM implements the JavaScript expression that you provide. Decision services cannot include Java or Web service integrations directly. You can call a Decision service from any other type of service, and a Decision service can call other nested services.
Human service Use to create an interactive service. A Human service is the only type of service that can contain coaches and postpones. Human services generate tasks in IBM Process Portal.
Ajax service Use when you want to include a control in a coach to implement dynamic data selection such as automatically populating drop-down lists and completing edit boxes. An Ajax service can pull data dynamically from a connected data source, such as a database. You cannot call an Ajax service from other types of services, but an Ajax service can call other nested services.
Integration service Use to integrate with an external system. An Integration service is the only type of service that can contain a Java or Web service integration. You can call an Integration service from any other type of service, and an Integration service can call other nested services.
Advanced Integration service
Use to integrate with a service that is created in Integration Designer.
Use to integrate with a service that is created in Integration Designer.
IBM Case Manager Integration service
Use to integrate with an IBM Case Manager server.
Use to integrate with an IBM Case Manager server.
General System service
Use to coordinate other nested services or to manipulate variable data. For example, to implement data transformations or generate HTML for a coach, you can use a General System service. General System services cannot include Java or Web service integrations directly. You can call a General System service from any other type of service, and a General System service can call other nested services.
Use to coordinate other nested services or to manipulate variable data. For example, to implement data transformations or generate HTML for a coach, you can use a General System service. General System services cannot include Java or Web service integrations directly. You can call a General System service from any other type of service, and a General System service can call other nested services.
Process Designer provides a context-sensitive component palette from which you can drag the components to construct the individual activities and the process definition.
For information about how to define a complete process, search for modeling processes in the IBM Business Process Manager V8.0 Information Center at:
8.6.5 Adding activity UIs
A business process consists of a set of tasks that are implemented through the various service implementations. A data steward or any user interacts with the business process through well-defined user interfaces. These interactions are implemented as Human services. Human services represent the actions that these users perform within the process. In BPM terminology, user interfaces are referred to as coaches.
The coaches in IBM Business Process Manager V8.0 are different in construction than the coaches in previous versions of IBM BPM. In versions before V8.0, the coaches of the previous versions of IBM BPM are referred to as heritage coaches. The primary difference between coaches and the heritage coaches of previous versions is that the new coaches consist of one or more coach views. Coach views are reusable collections of user interfaces that are frequently bound to a data type.
Process Designer provides a context-sensitive component palette from where you can drag the components to construct the coaches. Also, BPM supports complete customization of coaches, which means a custom hand-coded user interface can seamlessly be used with human services implementation.
For more information about defining coaches and implementing human services, search on creating user interfaces in the IBM Business Process Manager V8.0 Information Center at:
For example, to add a review and approval step to the Policy Enforcement and Remediation sample, drag the required controls from the component palette and wire them to the samples. Assuming you want to reuse the remediation UI, you can copy and then paste the existing coach controls.
8.7 Reporting for success
Enterprises that implement business processes need to monitor the processes from a performance and statistical perspective to further improve and optimize the process. IBM Business Process Manager provides ways to collect and use process performance information. The process applications can be designed so that they can be tracked by the monitoring framework of BPM.
In IBM Business Process Manager V8, the reporting function was deprecated. However, this function is compatible with earlier versions. The reporting function is not enabled by default.
To enable reporting, in Process Designer, click File → Preferences → IBM BPM → Capabilities. Then, enable the capabilities that are compatible with earlier versions. By using reports, you can analyze business data that is specific to your processes. You can specify the variables to track and define the report to query your tracked data. Users can view the resulting report scoreboards from the Dashboards page in Process Portal. However, in BPM V8, you can use more mechanisms for monitoring, tracking, and reporting purposes.
By using the Performance Data Warehouse, you can create customized reports by using third-party reporting tools in IBM Business Process Manager. To use this feature, you must identify the data elements that are required for tracking in the process. You send this tracking definition to the Performance Data Warehouse.
To track data in a business process definition (BPD), you can use the facilities of autotracking, tracking groups, or both. Autotracking automatically captures data from tracking points at the entry and exit of each item in a BPD (for example, services, activities, and gateways). Tracking groups provide more control over tracked data. You use them to track a selected group of process variables across multiple BPDs or process applications and to store tracking points for a timing interval. You can take advantage of both tracking methods in a single BPD. Use discretion when you model process definitions because the number of events that are captured for reporting impacts the process performance.
For more information about the configurations and steps for process monitoring, search for enabling processes for tracking and reporting in the IBM Business Process Manager V8.0 Information Center at:
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.