Multiple Solutions in one Tenant?

[stefankrauth]

Hi All,

Multiple solutions in one tenant may look attractive at first, but in most cases, it is not a good idea.

What is a solution?

An SDK solution can be seen as an Add On. It is a full package of code, extension fields, screens, services, etc. A solution can be downloaded an uploaded on other tenants that belong to the same customer where the solution got created.

Solutions are independent!

An SDK solution is working in an isolated namespace. It can access core SAP objects, but it can not depend on another solution. Therefore it is impossible to read, write or access content developed in another SDK solution within an SDK solution.

Real world problem with multiple solutions

• You have create a tab "Info" in the Account in Solution A. Now you would like to place a field from Solution B on it => not possible
• You have calculated the opportunity item summary in Solution A. Now you would like to add this information in a print form designed in Solution B => not possible.
• You called a web service in solution A. Now you need some data from the webservice in solution B => not possible
• You created a custom business object in solution A. Now you would like to write a reference to your object in solution B => not possible
• You created some extension fields in solution A. Now you have a MDRO developed in solution B which needs to access these fields => not possible.

Best Practice:

We recommend to do all enhancements for one Cloud for Customer installation in a single solution.

If you have two separate development tracks and if you are absolutely sure that no content in one solution will ever need to see, access, read, write, touch, reference or remotely use any content in the other solution now and in future, then you may decide to go with separate solutions.

[Jacques-Antoine]

Nice piece of advice Stefan!

But we do agree (in reference to your last affirmation in the blog) that if the solutions have nothing in common and do not share any information, it is a best practive to separate the solutions?

Sometimes it can be pretty inefficient to develop everything in the same solution. When you need to do some adjustments through a patch, and you only need to correct one o your 10 XBOs for example, you are taking risks for the whole solution.

I know we did not touch anything in the rest of the code, but we never know with IT. :smile:

I personally prefer to isolate the solutions that can be isolated.

Thank you for your blog!

Best regards.

Jacques-Antoine Ollier

[stefankrauth]

Hi Jacques-Antoine,

No, we always tell developers to work in one solution. The reason is experience. About 2/3rd of the projects that have started with "clearly separated solution that have nothing in common" got in trouble later on. Sometimes years later in another project phase.

Best Regards,
Stefan

[Former Member]

Hi Stefan,

Yes, I do agree to only have one solution. We have a lot of difficulty for those projects with multiple solution.

Which Deployment Unit would you recommend on the single solution approach? Should we always go with 'Foundation'?

Best Regards,

KH

[stefankrauth]

Hi KH,

In C4C always go with the CRM DU. Foundation is the underlying Deployment Unit and you can write through assiciations to Foundation objects. This does not work the other way around. If you create your solution in the Foundation DU, you can't create write enabled associations from Foundation object to CRM objects.

Also see: Understanding "Deployment Units"

Example Custom BO in Foundation which tries to set an association to the Customer (Foundation) and the Opportunity (CRM):

Example Custom BO in the CRM deployment unit doing the same as above:

As you can see, the custom BO in the CRM deployment unit can access objects in the foundation deployment unit without using cross deployment associations (read-only).

I hope this helps.

Best Regards,
Stefan

[PrasadRaghavan]

Nice blog Stefan. Thanks. However, with only one SOLUTION, deployment becomes a major challenge when too many people are working on the same SOLUITON. There are two major drawbacks to my knowledge 1. Granularity of deployment is not as fine as it is there in ABAP; We have to deploy the whole SOLUTION; This means, we have to ensure the whole team brings the developments to a logical end before deployment 2. There is not GIT available for SDK; Atleast this could have provided more flexibility during team work; Is there any roadmap to make atleast one of the above available in SDK going forward?

[davis_krastins1984]

Hi Stefan,

Nice!

Could you share your opinion on would be recommended infrastructure to support ongoing development and ruining production support simultaneously?

In this scenario it might be required to deploy fix small upgrade to production in the middle of release cycle, when logic of the release cycle obviously cannot be deployed to production, but you still want to deploy a quick fix/ small upgrade for current production solution.

[former_member200995]

Hi Stefan，

Nice！

The Deployment Unit of Solution A is CUSTOMER_INVOICING, and the Deployment Unit of Solution B is FINANCIALS.
I created custom business object bo_A in Solution A, and created custom business object bo_B in Solution B.
Now I am in Solution B, and I want to read the data from bo_A, not write, how can do it?

Best Regards,

Benny

 

[HorstSchaude]

Hello Benny,

As Stefan stated: "An SDK solution is working in an isolated namespace"

This is not possible.

Sorry,
Horst