Skip to Content

In the Central MDM Business Partner Creation Scenario with Galaxy (BPM) – Part I of this series I wrote about the scenario details as well as the Galaxy process model. In this part we will look into the architecture of the solution as well as implementation details.

It is easier to explain the solution if we talk from the Galaxy perspective. The following table explains what happens at each process step both in Galaxy as well as MDM:






































Process   step









Search for Business Partner



Search MDM repository



Not started yet



No suitable results, choose create



Record created with search parameters and checked out



Process start invoked



Edit record details



Retrieve record detail to show the already entered details   for addition



Parallel split for 2 agent roles



Agents submit details form



Modify the record in the repository after successful validation calls






Email notification






Invoke web service to send e-mail



Assign DUNS number






Invoke web service to generate DUNS number and assign it   to the record details in the process context



Assert approval method






Invoke rule to check for approval method



Manual Approval






Show record details from process context to approver



Auto Approval



Modify record with final details and check-in



Set approval status and invoke web service to check in the   record and end process



Manually approved



Modify record with final details and check-in



End process



Manually rejected






End process



The architecture of the solution can be described with the following diagram:


For communication with MDM various Java APIs from MDM were web service enabled via an EJB. Here’s a concise list:


























Web Service/Operation



Underlying APIs



Create record



MDMConnectorBeanService/ createBusinessPartnerRecord






Validate record



MDMConnectorBeanService/ validateBusinessPartnerRecord






Search business partner



MDMConnectorBeanService/ searchBusinessPartnerRecordByID






Check out record



MDMConnectorBeanService/ checkOutBusinessPartnerRecord



CheckoutRecordsCommand JoinCheckoutRecordsCommand



Check in record



MDMConnectorBeanService/ checkinBusinessPartnerRecord






Modify record



MDMConnectorBeanService/ modifyBusinessPartnerRecord



RetrieveRecordsByIdExCommand ModifyRecordCommand



When a new record is created in the MDM the ID of the checked-out record is returned and it is passed on to the process context. Using this record ID the different operations know which record to operate on.

Note that “JoinCheckoutRecordsCommand” has been used. Since the record is created and is checked-out before the process is started, all subsequent modification operations needed to join the check out first silently and then only could they modify the record.

It makes no sense to post coding details and so I will end the second part here. If you have questions regarding the code, post them as comments.

In the 3rd and final part I will talk about the BRM part with details on the rule and also on how the process is started remotely. Stay tuned!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Satyajit Chakraborty Post author
      The service enablement was needed because we used MDM SP06 and there were no web services available from MDM side for communication except for CRUD operations. In the future releases of MDM with the help of the web service generator there will be no need for this extra coding.

Leave a Reply