In SAP Hybris Cloud for Customer business objects are assigned to a particular Deployment Unit.
When developnig within a business object from the Foundation deployment unit, you will not be able to directly create an instance of a business object assigned to for instance the CRM deployment unit.
This issue has been addressed in the blog Understanding Deployment Units from Stefan Hagen. I encourage anyone who encounters Deployment Unit issues to go through that blog. It explains how to manage working with Custom Business Objects that reside in different Deployment Units.
In this blog I would like to discuss how to deal with situations where you would like to create objects, cross deployment units, from one standard business object to another. Let’s say we need to create a Lead (CRM Deployment Unit) from a Businesspartner (Foundation Deployment Unit). We can move a custom BO to the Leads’ Deployment Unit. This custom Business Object can now create Leads, but It cannot be changed by the Businesspartner to trigger the Lead creation. So what to do?
The Internal Communication object
In the SDK the Internal Communication object is made available. This special object automatically copies changes done in one custom BO and does the same changes in another custom BO. The two custom BOs do not need to be in the same Deployment unit. So, back to our case. We would like to be able to create a new Lead (CRM Deployment Unit) from a businesspartner (Foundation Deployment Unit). The approach would be to create two custom Helper BOs, one in each deployment units.
The two Helper BOs are connected by the Internal Communication object:
So the process looks as follows:
- The OnSave event of the Businesspartner contains the logic to determine whether a Lead should be created. If the Lead should be created, a change is triggered in the HelperBO_Foundation (create a new entry, or change an existing).
- The Internal Communication object picks up this change, and performs the same change in HelperBO_CRM. Its save event is triggered.
- In the save event of HelperBO_CRM we create a new Lead. This is possible since we are initiating the creation in the proper Deployment Unit.
: The Businesspartner has full access to HelperBO_Foundation, but no access to the Lead. HelperBO_CRM has full access to the Lead. The Internal Communication Object forms a bridge between HelperBO_Foundation and HelperBO_CRM which provide the Businesspartner access to the Lead.
In the SDK, the HelperBOs can be very simple but try to make the two HelperBOs identical. It makes the mapping more simple.
The HelperBO on the Businesspartner side:
As you can see, no explicit deployment unit is provided in the BO definition since the solution itself is created in the Foundation Deployment unit. The HelperBO on the Lead side:
Notice that here, we do need to explicitly specify the CRM Deployment Unit.
To create the Internal Communication object, add a new development object to your solution and navigate to: SAP->Service Integration -> Internal Communication
In the General tab you specify what the two communication HelperBOs are:
In the Message Structure tab, check all the fields except the technical SAP_UUID field.
In the Message Mapping tab, we provide the mapping, which is straightforward, given that the HelperBOs are identical:
The last important tab is the Instance Identification tab. This specifies how to determine the correct instances from the two HelperBOs:
Completing the End to End process
With these settings in place the cross deployment unit communication is ready. In the BeforeSave event of the BusinessPartner extension we can trigger a change in HelperBO_sender. This could be as simple as creating a new entry:
The same entry will be created in HelperBO_receiver. In its BeforeSave event we can trigger the actual Lead creation. This will work fine, as the HelperBO_Receiver and the Lead BO reside in the same Deployment Unit. Presto!
Debugging over multiple Deployment Units does not seem to always work as expected. Most of the times, while jumping from one Deployment Unit to the other, the debugger is lost. I would advise you to use trace messages to still keep track of what your code is doing. These will always show up in the Debugger Console:
Trace.Info(“<Generic message about a variable: >”, <any variable if applicable> );