Data Object Access Level best practise?

[former_member277448]

hello,

we are developing a project that has several Applications in it.

the Applications communicate with each other by the use of Function calls.

we have some data (the same value) that needs to be shared between the Applications.

one option is to define the data objects once and make their access level global so they can used where required.

the other option is to create the data objects where required and restrict their access to Application level and pass the data value via the Function call.

much debate in our team.

so, what is the best practise for this scenario? are their any significant pro's and cons?

thank you for any input.

cheers.

pas.

[christianlechne · Accepted solution]

Hi Pas,

from an organizational point of view I would recommend to store the reusable objects into a separate application. This way you make transparent that the objects stored there are used by several applications and a change on any of them has effects in several other applications.

Concerning the visibility I agree with Jocelyn, that moving between access levels can cause performance issues. Nevertheless I would not "hide" the reused objects within the applications they haven been orginally created in just setting the access level and component asignement correctly, but make it clear to the rule designers which objects are intended to be reused in which are not (as you would do it in ABAP).

Hope that helps

BR

Christian

[Jocelyn_Dart · Accepted solution]

Christian's comment reminds me what I forgot to mention - we did (as Christian has recommended) separate our most truly common and reusable objects and expressions into a central rules application.  We specifically separated out common Decision Tables, Decision Trees, and Constants, and put them in a central Catalog as well to assist business stakeholders and rule designers to find them.

More than just making it clear to rule designers and developers which objects were reusable, it also allowed us to multi-deploy the common rules application to multiple systems from Decision Service Management (btw if you don't yet have DSM you can also use XML Export/Import for the same effect) - so that rules applications in both of our systems could access the common elements.

There's always a balance here - too big a rules application becomes hard to manage, and it can become quite slow to work with it in the BRFPlus workbench; too many rules applications makes it harder to find the object you are after and building effective catalogs is trickier.

For the most part we went with putting related functions, mostly those that dealt with the same logical business object, together into the same rules application.  But it's a judgement call to balance performance in the workbench and during execution, against clarity of organization.

Good luck!

[former_member277448]

Thank you for you input Jocelyn and Christian.

much food for thought.

I have never really thought about object hierarchy but, if I understand correctly, it is possible to have a 'parent-child' relationship between applications (have I got that right?).

and this means that a data object created in the 'parent' application with Application Component access level should be visible in the 'child' applications.

the bit about the structure of projects (one big application versus many smaller applications) is something I am still struggling with. On one project I was involved in (although it did have several applications in it) the response in the workbench was glacial (literally minutes between mouse clicks) - we are in the process of refactoring this project.

Catalogs - I have not had much to do with so I do not really appreciate their value. I have come across enthusiastic comments about them in various discussions and blogs but I have not had the opportunity to investigate them.

so, my take from this is:

1. global is ok but it may come with a performance hit
2. Application Component access may be better
3. be careful how projects are structured.

once again Jocelyn and Christian thanks for your input.

[Jocelyn_Dart]

Hi Pas,

There are other levels as well. 

On my current project we are currently using Application Component but setting all rules applications to the same component hierarchy code.  This gives us much the same effect as global without some of the downsides that come with moving between global and other access levels (we previously came across some performance issues). 

It also means that if we change our minds later, or want to create another group of shared rules applications we can easily do that without impacting the original combination.

Btw if you are looking at a potential multi-deployment scenario, where some of your rules might need to be shared to more than one SAP server (e.g. CRM & ERP, SRM & ERP, etc.) then make sure the component you use exists in both systems.  One of the basis components is usually good for that, e.g. BC-SRV-BR itself.

Rgds,

Jocelyn