Hello,

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.

/wp-content/uploads/2015/09/du_787484.png

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.

read_only.PNG

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

/wp-content/uploads/2015/09/rep_787486.png

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.

bo.PNG

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.

To report this post you need to login first.

6 Comments

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

  1. Ludger Bünger

    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,

    Ludger

    (0) 
    1. Stefan Hagen Post author

      Hi Ludger,

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

      Best Regards,
      Stefan

      (0) 
      1. Ludger Bünger

        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,

        Ludger

        (0) 
    1. Stefan Hagen 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,
      Stefan

      (0) 

Leave a Reply