Blogs

MDM Developers

About this blog

The MDM Developers Community is open for any developers using IBM's Master Data Management software to connect with each other, stay posted on the latest MDM technical resources, learn how to get the most out of MDM tools, ask questions, and share tips and answers to technical problems.

Tags

Helps you obtain a vanilla instance of the MDM database with the gold data.

When to use:

In test instances, where test data has to be removed and the instance can be re-used.

In cases where database load failed during MDM configuration, due to issues like missing tablespace(s)

Please Note:

All tables in the schema in which MDM is configured will be dropped. A vanilla instance of the MDM database will be created containing database objects and gold data that come with the MDM installer. Customizations and rows inserted on a functional MDM instance will be lost. Hence, It is adviced to use this target in Development and Test instances only.

Invocation:

When the operating system is Windows:

Go to <MDM_INSTALL_DIR>/mds/scripts

Invoke madconfig recreate_database

In other operating systems

Go to <MDM_INSTALL_DIR>/mds/scripts

Invoke ./madconfig.sh recreate_database

Inputs obtained:

The database password

The WebSphere Application Server administrator user password

Other details on database configuration are obtained from mdm_install.properties found in <MDM_INSTALL_DIR>/properties folder. (In MDM v11.4 FP3 and MDM v11.5, other details are obtained from <MDM_INSTALL_DIR>/properties/db.properties)

Tasks performed:

Obtains user consent to proceed with database recreation

Stops the server

Drop all the triggers, foreign keys, indexes, sequences and tables in the given database schema.

Configuring MDM Standard Edition for external LDAP

Configurations to be done WAS Admin console of MDM.

Configurations to be done on imm file.

Configurations to be done on WAS Admin console:

When we are using external LDAP , we have to create federated repositories on MDM WAS. The reason for this being there are default groups like mdm_admin , mdm_all_cvws etc that are created during MDM installation.

Following are the steps to configure MDM to external LDAP using WebSphere Application Server Administrative Console.

Open up the WAS administrative console of MDM.

Navigate to Security -> Global security

Select “Configure” for Federated repositories and the screen would be like this.

Click on “Manage repositories” link under section “Related Items”.

Add a new LDAP repository. Details of the LDAP repository to be given are in the screenshot below. Need to specify the Primary host name and port number details for the LDAP which you want to use. Click on Apply once the details are given and this new LDAP repository gets added to the list of repositories for this WAS.

It will list down the new LDAP repository we have created. Select that repository. We also need to give unique distinguished name of base entry in this repository. For the sample LDIF file we have this would be the string “cn=localhost”. All users and groups from this LDIF file are created from this base entry. It could be different based on your LDAP.

Click on Apply and save configuration.

Now when we go back to Federated repositories it would look like this.

Save all the configurations.

We will now define how to identify groups uniquely in our LDIF file. A snapshot of the way groups defined in our LDIF file here :

We will have to now define this in our LDAP configuration in WAS. Go to the following link:

We have to make sure Object classes property is set to an appropriate value based on your LDIF or LDAP configuration. In this example it had to be “groupOfUniqueNames”.

We will now define how to get the relationship between users and groups uniquely in our LDIF file. Go to the following link Global security > Federated repositories > Manage repositories > LDAP1 > Group attribute definition > Member attributes If not present already create a new member attribute with “Name of member attribute” set as “uniquemember” and Object class as “groupOfUnqiueNames”. This is specifically for the LDIF configuration shown here where a user is associated with group by uniquemember/groupOfIniqueNames combination.

Save all the configurations and restart MDM server.

Configurations to be done on IMM in MDM Workbench

Open the imm file and in the Groups tab create a new group with the same name as the one in external LDAP. In our example it is “Group1”.

I will just take an example of giving users of this group ability to do read write access to legal name and do a memput interaction. Screenshots for the same

Save the imm file and do deploy hub configuration.

Now when we use SOAP UI to do a memput for PerLegalName attribute with these users present in group the txn is successful. Any other user from the LDAP doesn’t have access and MDM fails with the same error.

Tip : To make users from an LDAP group ability to login to inspector the list of Interactions that are to be given access are APPGETINFO , DICGET , USRGETINFO. Once done this we need to save it and redeploy hub configuration.

Note : If you create a user and group on WAS instead of external LDAP , in addition to doing imm config changes you would need to add the user entry to mpi_usrhead table.

Inquiry transactions for certain business objects in MDM use Optimized Transparent SQLs (OTS) to improve performance. These transactions include getParty, getPerson, getOrganization, getContract and getProductInstance. The OTS feature can be leveraged by setting value for property optimized.sql to true in TCRM.properties in com.ibm.mdm.server.resources.properties.jar. By default, this value is set to true.

The SQLs to retrieve the business object and child business objects can be found in table INQLVLQUERY.

When extensions are added to the business objects, the SQLs to obtain the business objects have to be regenerated so that the new attributes that are part of the extension are also retrieved. The SQLs in the INQLVLQUERY table can be regenerated using the updateInqLevel transaction.

When this transaction is executed with the GenerateQuery value set to YES (Y), the query corresponding to the given inquiry level and business transaction gets regenerated in the INQLVLQUERY table, such that it can return Attributes added using Extensions.

The list of Inquiry Levels(InquiryLevelId) and Business Transaction Type Code (BusinessTxType) for which OTS has to be regenerated can be found by executing the below SQL:

For example, for Person object, the below query can be executed:
select distinct inqlvlquery.inqlvl_id, business_tx_tp_cd from inqlvl, inqlvlquery where inqlvl.inqlvl_id = inqlvlquery.inqlvl_id and description like '%Person%'

Oracle database automatically creates a schema when a user is created. When a user logs in the default schema used is the one with the same name as the user.

In order for InfoSphere Master Data Management v11.6 to use a schema that is not the same the user name, the Logon Trigger given below has to be created and certain privileges have to be granted to the schema name (user).

Logon Trigger

The Oracle native driver does not provide a property to specify the schema name when the schema name is not the same as the User name. Hence a trigger has to be executed, when the schema that has to be used is different from the user name.

CREATE OR REPLACE TRIGGER LOGON_TRIGGER

AFTER LOGON ON DATABASE

BEGIN

IF (USER IN ('<USER>')) THEN

EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA = <SCHEMA>';

END IF;

EXCEPTION

WHEN OTHERS

THEN NULL;

END LOGON_TRIGGER;

/

In the above trigger, the placeholders <USER> and <SCHEMA> have to be replaced with the appropriate values.

Privileges to be granted

Create schema script that comes with MDM provides the below privileges to the user:

GRANT CREATE SESSION TO <SCHEMA>;

GRANT UNLIMITED TABLESPACE TO <SCHEMA>;

GRANT CREATE SEQUENCE TO <SCHEMA>;

GRANT CREATE ANY SYNONYM TO <SCHEMA>;

GRANT CREATE TABLE TO <SCHEMA>;

GRANT CREATE TRIGGER TO <SCHEMA>;

GRANT CREATE TYPE TO <SCHEMA>;

GRANT CREATE VIEW TO <SCHEMA>;

GRANT SELECT ANY TABLE TO <SCHEMA>;

GRANT IMP_FULL_DATABASE TO <SCHEMA>;

GRANT SELECT ANY DICTIONARY TO <SCHEMA>;

GRANT RESOURCE TO <SCHEMA>;

GRANT CONNECT TO <SCHEMA>;

GRANT CREATE SNAPSHOT TO <SCHEMA>;

In addition to the above privileges and access to tablespaces, the below privileges have to be granted:

GRANT SELECT ANY SEQUENCE TO <SCHEMA>;

GRANT ANALYZE ANY TO <SCHEMA>;

GRANT LOCK ANY TABLE TO <SCHEMA>;

The purpose for each Privilege is explained below:

GRANT SELECT ANY SEQUENCE TO <SCHEMA>;

This privilege is required to access sequences that are created during RDM installation.

GRANT ANALYZE ANY TO <SCHEMA>;

This privilege is required to execute SQLs which are found in Insensitive_search_enabled.sql which executes statements similar to the below:

Open up MDM stewardship toolkit and open up the Resource bundle with name “CoachLabels”. It already has the list of strings used in the UI and translated text for the default languages supported by BPM and MDM.

You can add a new Indian locale that is supported by this editor like Marathi, Punjabi, Gujarati, Tamil, Kannada and Telugu. For example lets add the locale Telugu(India) among the list of locales.

Once the locale is added , you need to put the translated text for each string in that locale.

Save once all the translated text for all the strings are given to the new locale added.

Take a snapshot of MDM Stewardship toolkit and upgrade the dependency in MDM Party Maintenance.

Create a new user using Process Admin console of BPM(for example user name is DSUserTelugu).

For the new user created mention the Locale in Process Admin Console as te-IN and update it. Screenshot for the same is

Now login with user “DSUserTelugu” in Process Portal and you should be able to see the localized strings in Telugu language for this user for Search dashboard.

Note : The Localization Resource editor should show a full list of locales existing in JRE. But some of the languages are missing definitely. For example Hindi is not present in the list to select and add translated text. So the workaround in such cases are these steps to be followed instead of steps 3,4 and 5 in the above list.

Localization Resource editor not only allows adding locales and keys one by one but also allows exporting/importing of a zip with multiple *.properties files.

Export the Localization resource “CoachLabels” from MDM stewardship toolkit as a zip file into your local filesystem.

Lets say you want to add Hindi(Locale code : hi_IN) support for this localization resource.

Add a new file called CoachLabels_hi_IN.properties file into this zip file and copy the contents from CoachLabels_en.properties.

After copying the contents translate the values to Hindi language by keeping keys same in this new property file.

Import this zip file back into MDM Stewardship toolkit and you see new locale Hindi coming up with translated text for Hindi.

Proceed with rest of steps 6 to 9 as mentioned above to use Hindi as locale for a user. Locale for the user to be mentioned in Process Admin Console in this case would be “hi_IN”.

The error ", already exists and INSERT_ONLY" may seem a bit cryptic. If you have ever encountered it on the add a record page in Inspector the good news is that it is very simple to fix. While it may look like there is a clash with the , the problem is in fact due to clashing memrecnos.

It may be that data has been bulk loaded, but the source sequence identifier settings have not taken this into account.

Firstly work out which memrecnos are already in use using the search by Source:ID option. Increase the ID in blocks until there is no data being returned.

In the workbench, go to the Source Sequence Identifiers window, connect the server and edit the entry for the source you are trying to add data too. Set the Next Identifier value to the next free value, and that will resolve the issue.

Other prerequisite software: IBM Business Process Manager 8.5.6 , IBM Process Designer 8.5.6, IBM Stewardship Center 11.5.0 installed and all process applications imported on BPM and EPVs for MDM Connection details set for all of them.

This blog provides detailed steps of connecting two MDM instances to a single Process center environment for IBM Stewardship Center(ISC) component. It provides the manual steps and doesn't do run any scripts. It also doesn’t explain all the steps required for installing and configuring ISC but only those additional steps when two MDM instances are involved.

This document assumes that you haven’t done any configurations on MDM or BPM WAS consoles for configuring ISC. If you have already done please delete those additional configurations.

Lets say you have two MDM instances MDM1 , MDM2 and single Process Center instance BPM1.

Steps to be done on WebSphere Administrative Console of MDM1.

1. Create an Alias Destination on MDM Server's SIBus as below:

a) Navigate to Service Integration -> Buses -> <BUS Name>
b) Click the <Bus name> link to open the configurations of the Bus.
c) Click on the Destination link to open the list of destinations.
d) Click on New and Select Alias and click Next

Provide the Destination attribute values:
Identifier: MDMBPMAlias
Bus: Select the SIbus of MDM environment. Note: The Bus name in typical MDM installation will be MDM.SIB.server1
Target identifier: Select Other, please specify from the drop down list. Specify the identifier of the BPM environment target. Note: Target identifier name in a typical Process center installation will be eventqueueDestination.SingleCluster
Target bus: Select Other, please specify from the drop down list. Specify the bus name of the BPM environment. Note: Target bus name In a typical Process center installation will be BPM.ProcessCenter.Bus
After providing the detail click Next
Click Finish.
Save the configurations

2. Create JMS Queue on MDM Environment as below:
a) Navigate to Resources -> JMS -> Queues
b) Select the scope. If it is a Standalone MDM server set it to Node, Server (Example, Node=mdmNode, Server=server1). If MDM installed in cluster, set the scope to Cluster
c) Click New
d) Select Default messaging provider and click OK
e) Set the values of the attribute as below:
Name: MDMBPMQueue
JNDI name: notification/MDMBPMQueue
Bus name: Select the SIbus of MDM environment. Note: The Bus name in typical MDM installation will be MDM.SIB.server1
Queue name: MDMBPMAlias
f) After setting the attribute values, Click OK and Save the configurations.

3. Create JMS Queue Connection Factory on MDM Environment as below:
a) Navigate to Resources -> JMS -> Queue connection factories
b) Select the scope. If it is a Standalone MDM server set it to Node, Server (Example, Node=mdmNode, Server=server1). If MDM installed in cluster, set the scope to Cluster
c) Click New
d) Select Default messaging provider and click OK
e) Set the values of the attribute as below:
Name: MDMBPMQueueConnectionFactory
JNDI name: notification/MDMBPMQueueConnectionFactory
Bus name: Select the SIbus of MDM environment. Note: The Bus name in typical MDM installation will be MDM.SIB.server1
Provider endpoints: It is generallyof the format “host:port:Inbound Transport Chain”. You can look at the existing Queue connection factories of MDM and get this value
f) After setting the attribute values, Click OK and Save the configurations.

4. Creation of Foreign Bus Connection on MDM Environment as below:
a) Navigate to Service Integration -> Buses -> <BUS Name>. Note: The Bus name in typical MDM installation will be MDM.SIB.server1
b) Click the <Bus name> link to open the configurations of the Bus.
c) Click on the Foreign Bus Connection link to open the list of destinations.
d) Click New…
e) Select Direct Connection and click Next
f) Select Service integration bus and click Next
g) Select the messaging engine on MDM environment from the list and click Next
h) Set the values of the attribute as below:
Name of service Integration bus to connect to (the foreign bus): Set the value to the name of the SIBus in BPM environment. Note: The Bus name in typical BPM Process center installation will be BPM.ProcessCenter.Bus
Gateway messaging engine in the foreign bus: Set the value to the name of the messaging engine of BPM environment. Note: The messaging name in typical BPM Process center installation will be SingleCluster.000-BPM.ProcessCenter.Bus
Service integration bus link name: MDM_BPM_LINK_ONE
Bootstrap service integration bus provider endpoints: Set the value as <bpmNodeHostName>:<port>:<protocol> (For example mdmdemowin:7278:BootstrapBasicMessaging) Note: If the BPM cluster has multiple nodes provide the endpoints for all the nodes as comma separated list.
i) After setting the values click Next
j) Review the summary and click Finish and Save the configurations

Steps to be done on WebSphere Administrative Console of MDM2

1.Create a new Service Integration Bus on MDM2. The reason for this to be done is because both MDM environments are identical and have same SIBus names connecting back from BPM will be an issue if BPM has to connect to two SIBuses with same name.
a) Navigate to Service Integration -> Buses -> <BUS Name>
b) Click New..
c) Give a name to the new SIBus to be created. For example MDM.SIB.NewBPMSer

2. For the new SIBus created , add a Bus member. This is required to create a messaging engine for the new bus created.
a) Navigate to Service Integration -> Buses -> <BUS Name>
b) Click the <Bus name> link to open the configurations of the Bus. Here click the SIBus created during step 1.
c) Click Bus members and Click on Add.
d) Choose the server or cluster to add to the new bus that got created. If MDM is installed on a server then server option has to be selected and the corresponding server. If cluster then the cluster option to be selected. Click Next.
e) If server option is selected , then you select option “Data store” in the type of message store. Click Next
f) If server option is selected, then select the option “Create default data source with generated JNDI name”in properties of data store. Click Next
g) Leave performance parameters as defaults and click Next.
h) Review the details and finish the configuration.

3. Follow steps 1 to 4 in the previous section. Wherever the SIBus name is required or to be selected , select the new Bus that’s created in step 1 in this section. Please note that while creating foreign bus connection provide the link name as “MDM_BPM_LINK_TWO” instead of “MDM_BPM_LINK_ONE” mentioned in the previous section.

Steps to be done on Websphere Administrative console of BPM

1. Creation of Foreign Bus Connection on BPM Environment as below:
a) Navigate to Service Integration -> Buses -> <BUS Name>
b) Click the <Bus name> link to open the configurations of the Bus.
c) Click on the Foreign Bus Connection link to open the list of foreign bus connections.
d) Click New…
e) Select Direct Connection and click Next
f) Select Service integration bus and click Next
g) Select the messaging engine on BPM environment from the list. Provide Inbound user id as admin user id of BPM and click Next
h) Set the values of the attribute as below:
Name of service Integration bus to connect to (the foreign bus): Set the value to the name of the SIBus in MDM1 instance.
Gateway messaging engine in the foreign bus: Set the value to the name of the messaging engine of MDM1 instance
Service integration bus link name: MDM_BPM_LINK_ONE
Bootstrap service integration bus provider endpoints: Set the value as <mdmInstance1HostName>:<port>:<protocol> (For example mdmdemowin:7276:BootstrapBasicMessaging)
Note: If the MDM cluster has multiple nodes provide the endpoints for all the nodes as comma separated list.
i) After setting the values click Next
j) Review the summary and click Finish and Save the configurations

Repeat the same steps but this time giving details of MDM2 instance. The values to be given in this case are

Name of service Integration bus to connect to (the foreign bus): Set the value to the name of the new SIBus created during step 1 in previous section in MDM2 instance.
Gateway messaging engine in the foreign bus: Set the value to the name of the messaging engine associated with the new SIBus created during step 1 in previous section in MDM2 instance.
Service integration bus link name: MDM_BPM_LINK_TWO
Bootstrap service integration bus provider endpoints: Set the value as <mdmInstance2HostName>:<port>:<protocol>.
If the MDM cluster has multiple nodes provide the endpoints for all the nodes as comma separated list.

So by the end of these steps you would have two foreign bus connections created on BPM. MDM_BPM_LINK_ONE pointing to MDM1 instance and MDM_BPM_LINK_TWO pointing to the new SIBus created on MDM2 instance.

Steps to be done on BPM Process Center console

1. Login to BPM Process Center Console with admin access
2. All the process applications for ISC are available at the installed location “<ISC_INSTALLED_FOLDER>/mdmg/processes”.
3. If not already imported you need to import all of them using Process Center console.
4. Create two snapshots “TESTSNAPSHOTONE” and “TESTSNAPSHOTTWO” for both MDM Party Maintenance and Physical MDM Suspected Duplicates process applications. Our focus is mainly on testing only these two.
5. Make all these 4 new snapshots Active.

Steps to be done on BPM Process Admin Console

1. Login to BPM Process Admin Console with admin access.
2. Go to Admin Tools > Manage EPVs
3. Select MDM Party Maintenance(TESTSNAPSHOTONE) and select EPV MDM_Connection_Details. Set the details of MDM1 instance over here. Provide non secure port for example 9080 for simplicity purposes, usessl option to be not checked i.e., set to false.
4. Select MDM Party Maintenance(TESTSNAPSHOTTWO) and select EPV MDM_Connection_Details. Set the details of MDM2 instance over here. Provide non secure port for example 9080 for simplicity purposes, usessl option to be not checked i.e., set to false.
5. Select Physical MDM Suspected Duplicates(TESTSNAPSHOTONE) and select EPV MDM_Connection_Details. Set the details of MDM1 instance over here. Provide non secure port for example 9080 for simplicity purposes, usessl option to be not checked i.e., set to false.
6. Select Physical MDM Suspected Duplicates(TESTSNAPSHOTTWO) and select EPV MDM_Connection_Details. Set the details of MDM2 instance over here. Provide non secure port for example 9080 for simplicity purposes, usessl option to be not checked i.e., set to false.

If you give snapshot names in the Process Center Console different than these make sure to change these SQLs as well. Make sure all the SQLs are run successfully.
If any duplicate errors come up while inserting data to BPMNOTIFICATIONTYPE table delete the existing entries causing the issue and run the sqls again.

Restart all the instances MDM1, MDM2 and BPM. You need to restart the Application servers, nodeagents , deployment managers.

Problem(Abstract)

When using InfoSphere Master Data Management (MDM) customers will see coredumps being created when an application server is being started or stopped in an environment with multiple application servers.

Symptom

There are several use cases that can lead to this behavior, all involve a WebSphere Application Server topology of more than one JVM in a clustered or non-clustered environment.

Some examples below:

- JVMs recycle by themselves no apparent cause
- JVM1 is up and running, JVM2 is started and causes JVM1 to crash
- JVM1 and JVM2 are up and running, runbatch.sh process is started and causes JVM1 to crash
- JVM1 and JVM2 are up and running, if a user attempts to stop JVM1 or JVM2, the JVM that is being stopped crashes

Cause

Diagnosing the problem

The javacore and heapdumps will have two things in common:

1. The crash occurring in the ld-linux-x86-64.so.2 library (Red Hat Linux) which is called from dlsym() call in the JVM
2. A process tries to access the libMAD.so library (MDM) from an existing JVM causing it to crash

Contact IBM Support if you suspect you are experiencing this issue. Ensure the MustGather: Crash on Linux is followed to collect all required information and that the core has been processed through jextract.

Resolving the problem

In order to have immediate relief to this issue a workaround is available.

Note:
chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders.
The defect seems to be opening/closing the libMAD.so, setting this property will prevent such activity, which will prevent the crash.

IBM Stewardship Center provides the ability to perform proactive data stewardship activities around Physical MDM. When a suspect gets created on MDM , a notification is being sent to BPM and a Suspected Duplicate task gets created on BPM Process portal for a Data steward to act upon. This can be disabled if the Customer has huge number of suspects especially during intial load or the tasks creation rate is slowing down the process or Customer already has suspects and want to create tasks for them in BPM.

This document explains how to create SDP tasks on BPM Process Portal by fetching suspect data from MDM database.

Steps to be done on BPM Websphere Administrative Console.

1. Create a new Data Source to point to MDM DB.

Please make sure to give the data source name as “jdbc/MDMDB”. Something else can be given too but then you would need to change in the process application for that.

Please make sure to give correct database name, server name and port number related to MDM database.

2. Provide correct values for "PHYSICAL_SDP_PROCESS_APP_SNAPSHOT" and "MDM_DATA_SOURCE_JNDI_NAME" in Process Admin console under Manage EPVs for the snapshot drop down selected as "SDP Create tasks". Screenshot for the same.

3. Run the service "Create SDP tasks" from the same Process Admin console. It is available as last item on the left hand side menu as shown in previous screenshot

This service creates SDP tasks for all the suspects fetched from MDM. It first checks if a task is existing for a Party Id. If not present it creates a new Suspected Duplicate task.This needs to be customized if a Customer wants to get only some subset of supect list and so on. The SDP task thus created is available on BPM Process Portal for a Datasteward to act upon.

Communication from MDM to BPM for IBM Stewardship Center is always via messaging. In case of some specific events happening on MDM, the events are to be notified to BPM to create a new task. BPM can only listen to messages that are put in its event queue. To make this possible we create a link between MDM and BPM. MDM can be installed with MQ as messaging provider. BPM suggests to use only WAS default messaging provider. To be able to send messages a Customer needs to do these steps

Configuration steps on MQ associated with MDM installation.

Configuration steps on WAS Admin console associated with MDM installation.

Configuration steps on WAS Admin console associated with BPM installation.

Configuration steps on MQ using MQ explorer

1. Create a new Sender channel under the Queue manager that is default created for MDM. installation.

2.Create a Receiver channel under the Queue manager that is default created for MDM.

Channel name : Could be anything. In our setup we named it BPMReceiver.

Transmission protocol : TCP

3. Create a local queue with usage type as Transmission under the Queue manager that is default created for MDM.

Queue name : Service Integration Bus name of BPM. In our setup the SIBus name of BPM server is BPM.ProcessCenter.Bus hence the same given.

Scope : Queue manager

Usage : Transmission

4. Create a remote queue under the Queue manager that is default created for MDM.

Queue name : Could be anything. In our setup we named it EVENTRQ.

Remote queue manager : Service Integration Bus name of BPM. In our setup the SIBus name of BPM server is BPM.ProcessCenter.Bus hence the same given.

Transmission queue : Same name as given for the queue name in previous step. It is same as Service integration bus name of BPM. In our setup it is “BPM.ProcessCenter.Bus”.

Remote queue : Destination name for which messages are to be sent on BPM Service Integration bus. Check for destination name that starts with eventqueueDestination in the list of destinations under SIBus for BPM Server.

5. Start channels created on step 1 and step 2. Sender channel created in step 1 should be in running state.

This completes list of steps to be done on Websphere MQ Explorer. Now we will see the list of steps to be done on MDM and BPM installations.

Configuration steps on Administrative Console of WAS where MDM is installed.

1. Create a new Queue Connection Factory with following details.

Navigate to Resources -> JMS - >Queue Connection Factories. Select New to create a new one.

Create it at the same scope as existing Queue Connection Factories.

Select JMS resource provider : WebSphere MQ messaging provider

Name : MDMBPMQueueConnectionFactory

JNDI name : notification/MDMBPMQueueConnectionFactory

Select ‘Enter all the required information into this wizard’

Queue manager or queue sharing group name: Name of the Queue Manager that gets created from MDM installation. In our setup it is QM.E001

Hostname: Hostname of the MQ machine where this MQ is running and Queue managers are created by MDM installation. In our setup it is localhost.

Port: Port number where this Queue manager created by MDM installation is listening. In our setup it is 1414.

2. Create a new Queue with following details

Navigate to Resources -> JMS - >Queues . Select New to create a new one.

Create it at the same scope as existing Queues.

Select JMS resource provider : WebSphere MQ messaging provider

Name : MDMBPMQueue

JNDI name : notification/MDMBPMQueue

Queue name : It should be same as the remote queue name created in previous section in step 4. In our setup it is EVENTRQ.

Queue manager or Queue sharing group name : Name of the Queue Manager that gets created from MDM installation. In our setup it is QM.E001.

Save all and restart WAS for these configurations to take effect.

Configuration steps on Administrative Console of WAS where BPM is installed

1.Create a new foreign bus connection to the existing Service Integration Bus of BPM.