Best Practices for Naming Conventions - ESR Objects

[former_member188019]

Hi,

As per the doc "Best Practices for Naming Conventions" https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90b213c2-d311-2a10-89bf-956dbb63...

In this doc, we see there are no prefixes or suffixes like DT_ for data types, MT_ for Message types, SI_ for service interfaces OM_ for operation mappings (MM_ in message mappings in earlier versions).

but i have seen some people maintain these kind of conventions.

For larger projects, what is the best option,

A) to strictly follow the instructions in the above document and not to maintain the object type prefixes or suffixes.

B) or to have this kind of prefixes in addition to what mentioned in the naming conventions doc.

which is preferable, from point of long term maintainance.

i would appreciate an opinion/guideline from people who had worked on multiple projects.

thanks,

madhu.

[former_member192295 · Accepted solution]

Hi,

We can't follow specific naming standards for project. Every company have own standards, depending on clinet standards we need to follow. Recently i have done one banking project. Bank have own naming standards for declare variables meanwhile bank each clients have own standards. Better to follow client standards, if client don't have any standards then we can follow your mentined document standards.

I hope now clear

[former_member188019 · Accepted solution]

>NALLAM GUNA RANJAN wrote

>>if client don't have any standards then we can follow your mentined document standards.

the client is newly using sap pi 7.1, so we had to chose one.

one more point brought up by our team is that.. if were in 7.0, then we would have used MM_ for message mapping, but after it gets upgraded/migrated to 7.1, the object becomes operation mapping with the prefix MM_.

so kind of elaborating if it can be kept or not.. i think since we are already in 7.1 we can safely use OM_ and SI_ and we may not expect object type name change in future versions...

the other team members said, if we skip these prefixes, the version issue may not arrive.

[Former Member · Accepted solution]

Hi,

Better go for standards suggested by SAP as basic idea is behind this is harmonization of services.

Regards,

Gourav

[former_member192295 · Accepted solution]

Hi,

I think naming standards not depends on version. If client new setup mean we can follow your mentioned document. Generally DT,MT MIO,MII,MM,IM prefix naming standards will use in most of XI/PI projects, why because these naming conversion every one can understand easily.

[Former Member · Accepted solution]

Hi,

with SOA coming to picture things are changing rapidly. DT/MM etc suggested by SAP and adopted by many, similarly SAP is suggesting new naming convention for harmonization and with new version you have much more things like "Business Objects", Multiple operation per service which is true reflection of webserve than PI7.0/XI3.0

Regards,

Gourav

[former_member188019 · Accepted solution]

thanks for the replies.

finally we are proceeding without using SI_ , OM_ as we will also be using enterprise services provided by SAP HCM, FICO etc, and the standard service interfaces provided by sap don't contain SI_ prefixes/suffixes.

i hope SAP will release a new naming conventions document for PI 7.1, that includes guidelines for naming of Function Libraries, Communication Channel templates, Business Component names etc that are introduced in 7.1.

[Former Member · Accepted solution]

Hi,

Naming convention is available for PI7.1, search SDN. I was using same successfully and strongly recommend to everyone. It really make good sense to use SOA based naming convention.

See this Guide in 6 part: Enterprise SOA Object & Service Operation Design Part I of VI Documentation and Naming Guideline

One guide url is: https://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d05a91ba-9201-2c10-83b5-9ab989523bcf&overrid...

Close this thread if your question is answered.

Regards,

Gourav

Edited by: Gourav Khare on Jul 30, 2009 6:38 PM

Edited by: Gourav Khare on Jul 30, 2009 6:39 PM

[former_member188019 · Accepted solution]

thanks Gaurav..

>Gourav Khare wrote

>>I was using same successfully and strongly recommend to everyone

okay thats "Best Practices for Naming Conventions" https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90b213c2-d311-2a10-89bf-956dbb63... this one i think.

>>One guide url is: https://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d05a91ba-9201-2c10-83b5-9ab989523bcf&overrid...

this one seems to be based on SOA, and not just specific to PI 7.1

[Former Member]

Hi,

There are 2 type of naming convention exist in ESR

1. PI way: like using DT/MT etc but only when PI7.1 is used as a midlleware not SOA backbone.

2. Another naming convention is to suite SOA development.

Naming convention then have following part, Business Object, Interface Pattern, Communication Pattern,

Approach1:

Service Interface: <Manage/Query> <BusinessObject> <Sync/Async>_<In/Out>

Service Operation: <Create/Update/Delete/Change/Read><BusinessObject>

Message/Data: <BusinessObject><Action(Update/Delete/Create etc)><Request/Confirm/Response>

Approach 2: You will see this in most of the SAP ES.

<BusniessObject><Action><Request/Response><In/Out>

Note: SOA approach not focus on reusability of objects but on stability of interfaces.

Regards,

Gourav

PS: you are free to follow any approach but if you want to qualify it as enterprise service and harmonized service SAP recommend approach suggested by SAP, as everyone will follow same approach then it is easy to realize hormonization across companies.

Edited by: Gourav Khare on Jul 30, 2009 1:45 PM

[Former Member]

For larger projects, what is the best option,

A) to strictly follow the instructions in the above document and not to maintain the object type prefixes or suffixes

--> Strictly..means lack of flexibilty..Prefixes and Suffixes helps the developer as well as other persons in the project to understand the context and technical usage in their own way.

B) or to have this kind of prefixes in addition to what mentioned in the naming conventions doc.

I always prefer prefixes and suffixes..as it helps me in finding out objects quickly..in search, plus maintenance is easier..and this can be used as future guidelines for the coming developers..

And also the naming convention guide is as per the business language not a sper the technical approach.

For Ex. : I would prefer DT_Address as a Data type for Address and MT_Address as message type for address.

rather than naming Address or address1.....etc as message type as well as data type...

[former_member200962]

We keep the naming convention document as the base document and then build the customer specific naming convention

Using prefixes is not only a good option for the developers/ code reveiwer but also for the maintanence/ support folks

So my suggestion would be you refer to the convention document as a guide and not as a rule book.....

Regards,

Abhishek.

[Shabarish_Nair]

>

> Hi,
> 
> 
> As per the doc "Best Practices for Naming Conventions" https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90b213c2-d311-2a10-89bf-956dbb63...
> 
> In this doc, we see there are no prefixes or suffixes like DT_ for data types, MT_ for Message types, SI_ for service interfaces OM_ for operation mappings (MM_ in message mappings in earlier versions).
> 
> but i have seen some people maintain these kind of conventions.
> 
> For larger projects, what is the best option,
> A) to strictly follow the instructions in the above document and not to maintain the object type prefixes or suffixes.
> B) or to have this kind of prefixes in addition to what mentioned in the naming conventions doc.
> 
> which is preferable, from point of long term maintainance.
> 
> i would appreciate an opinion/guideline from people who had worked on multiple projects.
> 
> thanks,
> madhu.

I have seen projects where they are specific to having DT_, MT_ prefixes and also projects which dont use them.

Even though you dont have a DT_ or MT_ prefix for DT and MT, it would be essential to have AA, OA, OS, IS etc defining a message or service interface that will give you an idea of the mode and direction of the interface.

On a generic term, i strongly feel that the naming conventions suggested by the document is quite enough to accommodate a large number of projects unless something very specific pops up.