Usage of standard functions in custom code is not something new, and in my experience standard functions are one of most used artefacts in customer code.
When using standard functions release status is one of the most important topics that come up quite frequently.
At the end of this blog you should be able to identify whether a standard function is ok to use in customer code or not. Also, what can be the implications / risks introduced by using such an object.
Different types of functions in SAP:
- Released for Customer Use.
- Not Released for Customer Use.
- Internally released.
Know your function:
Released for Customer use:
- Go to transaction “SE37” type in a standard SAP function name for this exercise let’s look at a function named “READ_TEXT” and click on Display.
- This opens the attributes of the function in SE37. Look for Released status field on the right side of screen.
- Released status should be “Released On” followed by the date when it was released.
- If a function is in this status it is safe to assume you can use it in Customer code.
- Go to SE37 – Enter – “REUSE_ALV_BLOCK_LIST_INIT” click on display.
- Check the attributes on Released status. You would notice the function is internally released and no dates are available.
- Follow the same steps as before going to SE37 in this example type in standard BAPI -“BAPISDORDER_GETDETAILEDLIST” click display.
- Check the attributes and you will find function is not released – This indicates the BAPI is not released by SAP to use in Customer code, and SAP reserve the rights to this function.
Now I know the different function status:
- Benefit of open source code application is you can find re-usable components and use them in your code.
- But by using Not released or internally released functions you potentially undertake a risk, sometimes without knowing.
So, what does this mean if I use a Not released function/ Internally released function in a customer code?
- By setting a function to not released / internally released status SAP is directing customers to expect future changes in these codes.
- After the customer code is build and deployed to production another support package or via an OSS note application SAP reserves all rights to change the function or even delete if necessary.
Does this mean we should never use the functions and try to build our own customer code?
- No, we don’t have to. We cannot reap the benefit of Open source code if we cannot use Re-usable library.
- Also, there will be scenarios / requirements when I cannot do anything else except using a not Released / Internally Released function.
A strong Code base Governance and control is needed to minimize risk of using such a function.
It is an established concept that we cannot always avoid Not Released / Internally Released functions, and these objects can be changed during anytime without notice.
- Try to find alternative to a not-released function first to meet your requirement.
- If no alternative is available ensure support organization is aware of this usage and will keep a look out during upgrade or OSS note implementation.
- Create a repository of these functions that are used in Custom code and where they are used.
- There are multiple ways to do this.
- In my experience co-ordinated teams maintain these in Excel, Access Db.
- Very innovative developers create a where used list within SAP to manage this.
- From Monitoring point of View Early watch report and other tools can be used to ensure system is running smoothly.
Note: This article is only applicable for standard SAP functions, for functions that start with Y or Z the code is within customer name space so released status is not relevant.