TKS # 10 - How to Code? Access the Planning Profile

[Tobias_Berger]

Profile Facade

With the last years of development, the planning profile and subsequent settings developed to be more than normal BOBF BOs. They a basically a normal BO in their own maintained but with the possibility to transient changing throughout planning sessions and have one of them standing out to be the one and only default profile.

With the increasing features differentiating the profile from normal BOs it was necessary to think about an own level of abstraction and an own (refactored) path to access the profile. This blog should make you aware of this fact and enabling you to access planning profiles correctly in your own developments which is sadly not just the good old service manager retrieves.

Already from the early beginnings planning profiles where hidden by a facade class, which had the horrible name /SCMTMS/CL_PROF_DETERMINE_SETT. With newer developments taken place in the 2020 release there was a new class taking the position which is /SCMTMS/CL_PROF_ACCESS_FACADE. And what a facade it is! Basically the facade is used to create the anchor point for accessing profile data. If you use it, you should be on the save side and it's at least for me it's even easier to use retrieves.

An instance of this class can get created using the following statement:

/scmtms/cl_prof_factory=>get_factory( )->get_prof_access_facade( ).

With that you should have what you need to get whatever information from the profile. Let me explain the different important methods what they are offering:

• CONVERT_PLAN_PROF_ID_TO_KEY  - quite obviously conversion from the planning profile ID to the key


• GET_PROFILE_DATA - this method offers all different settings tables which are relevant from the planning profile and all it's sub-profiles. You don't need to use the associations on your own and the method will take care of replacing information with the default profile once. Form my perspective this is the most important method to be used for profile access.


• GET_SETTING_TOR - this method can determine the correct planning profiles to be used for a number of TOR documents. Usually in the transportation you will only get one profile back for all while called from POWLs or other processes which aren't specify a fixed profile it might differ for the different TOR documents

Behind the profile facade there is a lot of complexity hidden to the developer who shouldn't need to care about all that, when implementing business processes. If you are need to understand more, e.g. for understanding an issue, you can check out the following figure:

 

Planning Profiles - Overall Class and Package Structure

 

CRUD operations on profiles

Sometimes you might need to implement a report doing CRUD operations on profiles. For those you can make your live easy using the common API classes. You can instance one using:

/scmtms/cl_prof_factory=>get_factory( )-> GET_COMMON_PROFILE_API( <Profile_bo_key> ).

With this class you can do all the CRUD operations on standard profiles on an "easy-to-use" level. Furthermore, you can convert profile key to id and vise-versa.

Mocking Planning Profiles

Mocking planning profiles from TM processes is made rather easy. You can use /SCMTMS/CL_AUNIT_INJ_PROFILES to inject a profile which will be returned from the facade from that time on. You specify certain profiles and leave others out. For those the system hard-coded default values will be assumed. Those will only change in rare cases (for more on this one see my blog Default Planning Profile – What is it and why was it implemented?).

Conclusion

With those classes at hand, it should be far easier to access profiles from a developer perspective. Furthermore, you should always use those classes - as otherwise you will not get correct default values from the system.

For sure in the area of the profile single UIs coding calling the service manager is still mandatory as other calls might run into the issue of the additional caching layer which is introduced through the facade.