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 | MDM | Galaxy |
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 | Join |
Email notification | None | Invoke web service to send e-mail |
Assign DUNS number | None | Invoke web service to generate DUNS number and assign it to the record details in the process context |
Assert approval method | None | Invoke rule to check for approval method |
Manual Approval | None | 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 | None | 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:
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!