Skip to Content
Author's profile photo Stefan Hagen

Understanding “Deployment Units”


Sometimes issues are coming up where you cannot update fields on objects that are flagged as writable in the repository viewer. This is often the case, when your solution has been assigned to a deployment unit, which can not write to the business object you’re trying to update.

Why does this happen?

When you create a Solution, you’re asked to assign it to a deployment unit.


In this case, the deployment unit “Foundation” has been chosen. This leads to the behavior, that all custom business objects created in this solution will be created in the deployment unit “Foundation”.

But what happens if you would like to access a business object in another deployment unit? Let try to update the delivery date of the purchase order.


This will lead to an error. But why? According to the repository explorer, write access is allowed!


But the repository viewer also shows another information. The PurchaseOrder got greated in the deployment unit “Purchasing”. Due to the logical encapsulation of the ByD units, only read access is allowed cross DU.

How to overcome this limit?

Well, this can be easy or difficult depending on what you’re doing.

Option 1: You can “move” the custom business object to the Purchasing deployment unit. Then it will live next to the Purchase Order and has write access. This can be achieved with the annotation [DeploymentUnit(Purchasing)] in front of the business object definition.


Option 2: The more difficult usecase is, when you have one object that needs to write to multiple objects in different deployment units. Then you can’t move the business object to one deployment unit without losing write access to the other one. In this case you can create a helper business object in the read only deployment unit and communicate with it using a webservice. This case happens only in very rare cases.

Special deployment unit “Foundation”

The deployment unit “Foundation” is an exception. It is the underlying deployment unit and all other deployment units have write access to the Foundation (but not the other way around!). Therefore it is advisable to create a solution in the deployment unit that matches the purpose of the solution. Creating a solution in the Foundation deployment unit should only be used if you only need write access to master data objects.

I hope this helps you to understand deployment units a bit better.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      A quite helpful blog entry.

      Just one additional detail for the fellow reader:

      You also cannot create associations to Business Objects located in a different deployment unit (except Foundation).

      More precise: technically you can create an association using the CrossDeploymentUnit annotation but this only means you can access the object for reading via the association in queries (and data sources i believe) only, not in regular code.

      Best regards,


      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Ludger,

      thanks for adding this information. Yes, this applies to all access forms. Retrieves, Associations and Queries.

      Best Regards,

      Author's profile photo Former Member
      Former Member

      Ok, thanks.

      But is there a reason for this "no association rule"?

      Since I can read-access other-DU objects, associations _do_ make sense.

      Currently instead of simply following the association I have to store the key of the other object, do a retrieve, check for read success and finally read the fields I require.

      And this needs to be repeated in every action.

      Best regards,


      Author's profile photo Former Member
      Former Member

      And you can't use a cross deployment unit association in the UI. Only the UUID.

      Author's profile photo Former Member
      Former Member

      Hi Stefan,

      I always wondered what are the benefits of 'this limit' ?


      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Fernando,

      the idea is, that these deployment units are not tightly coupled. They communicate with each other using internal webservices instead of direct LCP calls. This gives us the theoretical benifit of being able to replace a whole deployment unit with something new, without having to refactor the whole stack. It's a module concept...

      I think modules have been added, but never removed or replaced. But theoretically, it's possible.

      In C4C, the world is a bit different as there are only two deployment units: CRM and Foundation.

      Best Regards,

      Author's profile photo Former Member
      Former Member

      Hello Stefan,

      very good blogs!


      One issue I got:

      I have two SAP standard BO's in different deployment units.

      For each of them I created an extention.

      Now I have to update from BO "BusinessACtivityToIndustry" a field in the BO "ServiceRequest".

      I used option 2 with a webservice. Working, BUT not offline on mobile app (my finding so far).


      How can I "move" one BO to an other deployment unit, without currupting the whole SAP logic?

      I assume the answer will be: Not possible.... 


      Any idea?



      Author's profile photo Vincent Vancalbergh
      Vincent Vancalbergh

      Isn't an "Internal Communication" object intended for this? (allthough personally I don't like them because they are complicated to set up and fire asynchronously)

      Author's profile photo Santosh Kayarat
      Santosh Kayarat


      Internal Communication does not work, in all cases. Let me provide a use case:

      If I want to run PGIInBackground() action from Site Logistics module, instead of creating a whole new solution for this purpose, a simpler way is to annotate that particular BO with associated deployment unit. This provides unprecedented access.Setting up an internal communication is a tedious process, for such cases.

      Always feel a better process is to do away with Internal Communication as much as possible.