This is part 2 of my series on best practices. You might also want to read the reason for creating this series on SAP PI/PO best practice. In this post, I will share further topics I wish to cover in the series. Furthermore, the contents of a best practices document will be discussed in depth.

InvoiceCreation_IA-300x300.pngAn essential element of the developer’s handbook is the naming convention, which covers the naming of all objects used in an integration. Naming is important because it cannot be changed without a lot of work. There is no easy way to rename objects because of the many places where the names have been used.

The downside of choosing object names – and then having to change them – is that you first realize how they work only after you have made your way through a considerable chunk of your projects, and after so much invested time you cannot change the names without a lot of waste.

IFG (The International Focus Group for Integration) has the only updated naming convention. New information has been added to keep up with new data types. Ask your local user group for the document.

SAP also has its view on naming conventions. The document was created in 2009, but it does contain the most used objects that are still the main focus of SAP users:

Let these documents work as a way to get leads for your own custom document. It does not have to be as lengthy – it can be a 3 pages long summary with some of the names that you will be using.

One big issue arises if you want to have prefixes on all objects, like OM_ , before operation mapping. It may make it easier for new developers to understand what has been developed. However, it is just extra information that I do not consider useful, so I would skip it if possible.

I recommend the use of the business object that you are working with. For example, Invoice could be that business object. Then you have got different posts and prefixes on, like InvoiceCreation_IA or whatever you prefer.

The other important discussion is about where to place the objects. The general SOA (service-oriented architecture) approach was to create two interface components, e.g. one for the SAP ERP (Enterprise Resource Planning) system, and one for the third-party system. They would have information about the interfaces; sometimes they could contain some logic (but not most of the time). Then there could be mappings in a PI (Process Integration) or Application component.

The other way is to have one software component per software that you want to integrate, and then place mappings and an interface in this. This may make some things much easier to transport and develop on. There is not much reuse in this approach, but in general it is difficult to get to the “Generic” components that can be reused all over again.

There cannot be one document that covers all cases. Sometimes developers have to make intelligent decisions to get away from the naming convention, enabling a method of differentiation. You will not be able to handle all cases in the beginning, or you will probably spend too much time on them.

I think the biggest mistake that companies make is forgetting about the naming convention, and hoping they can make it right along the way. As it turns out, it can be quite expensive to change something at a later point.

In other situations, they just take one of the standard templates and use it as their own. If they do not have local ideas, it becomes too difficult to make decisions, and developers have to figure things out on their own.

My best advice is to have a workshop with some consultants, preferably with different backgrounds, when you have an idea of what you want to accomplish, while also possessing enough knowledge on what types of integration will be the primary area of expertise your project requires.

What’s your opinion on naming conventions? Would you make some changes halfway through a project?

This post orginal appered on

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply