Applies to:

This Document Holds good for all CE 7.XX and PO 7.4 .


Summary:

This is a Naming Convection guide used for Modeling of BPM.


About Me:

Piyas Kumar Das

As a Sr. Netweaver Consultant, I’ve been undertaking consulting assignments leveraging on my undermentioned NetWeaver skills.

  • Business Process Management (SAP NW BPM)
  • Restful Services using BPM api to be used in UI5 Screens.
  • SAP Web Dynpro Java (SAP WD4J)
  • SAP Business Rules Management (SAP BRMS)
  • SAP Composit Application Framework (SAP CAF)
  • Master Data Management (SAP NW MDM)
  • Enterprise Portal (SAP EP)
  • Services creation using NWDS (SAP EJB)
  • Enterprise SOA


I am an SAP BPM Trainer, an Active Blogger and Document Writer in SCN.

1.     Naming Conventions

1.1 Development Component’s (DC’s) Name

Vendor

<Company Name>.com

Name

<Project Name>/<Process Repository>/<Other Detail’s>/bpm

Example:

Vendor

sap.com

Name

masterdata/customer/creation/bpm

1.2 Process Name

Name

<Process Details>

Example:

Name

Sold_To_Party_Creation

1.2.1 Pool Name

Name

<Process Name>_Pool

Example:

Name

Sold_To_Party_Create_Pool

1.2.2 Lane Name

Name

<Lane Owner / System>_Lane

Example:

Name

Initiator_Lane

ASM_Lane

ECC_Lane

Other_System_Lane

1.3 Task Name

Name

<Task Details>_Task

Example:

Name

Sold_To_Part_Approver_Task

Approve_ShipToParty_Task
Review_Supplier_Task

1.4 Event Triggers

1.4.1 Messages

Name

<Message Event Trigger Type>_MT

Example:

Name

Start_SoldTP_Create_BPM_MT

1.4.2 Escalations

Name

<Escalation Event Trigger Type>_ET

Example:

Name

SoldTP_Completion_Deadline_ET

1.5 Reporting Data Sources

Name

<Reporting Data Type>_RDS

Example:

Name

Sold_To_Party_Creation_RDS

1.6 Rule Sets

Name

<Rule Set Data Type>_RS

Example:

Name

SoldTP_Creat_ApprovalLevel_RS

1.7 Functions

Name

<Function Type>_FNS

Example:

Name

List_To_String_FNS

1.8 Data Types

Name

<Data Type>_DT

Example:

Name

Sold_To_Party_DT

1.8.1 Complex Types

Name

<Complex Type>_CT

Example:

Name

Credit_Limit_CT

1.8.2 Data Objects

Name

DO_<Data Type>

Example:

Name

DO_Sold_To_Part

Name

<Data Type>_DO

Example:

Name

Ship_To_Party_DO

1.9 Service Interfaces

Name

<Service Type>_SI

Example:

Name

SoldTP_Start_CreatBPM_SI

1.9.1 Operation Name

Name

<Operation Type>_OP

Example:

Name

Create_SoldTP_Start_OP

1.9.2 Request/Response Name

Name

Request/Response_<Data Type>

Example:

Name

Request_SP_CheckCreditLimit

Response_SP_CheckCreditLimit

Request_ Approve_ShipToParty
Response_ Approve_ShipToParty
To report this post you need to login first.

5 Comments

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

  1. Tilman Ulshoefer

    Hello Piyas,

    That’s a great overview to share here. One question:

    Why do you go for underscores? For consumers underscores are very technical and not natural language, that’s why I always recommend to follow natural writing, i.e. with blanks instead of underscores.

    Best regards,

    Tilman

    (0) 
    1. Piyas Kumar Das Post author

      Hi Tilman,

      I agree with you we could use natural writing, but the problem with that arises when we try to use the Standerd OData Service which come out of the box.

      So if we use underscore i agree it looks technical but it makes life easy in other parts as well.

      Cheers

      Piyas

      (0) 
  2. Jocelyn Dart

    Hi Piyas,

    It’s great to see this being putting together collaboratively.

    Generally like the look of it… I agree please don’t use underscores where they are not necessary – especially process, lane, task names.

    Including for OData reasons is of course fine.. but we shouldn’t have to put underscores everywhere just because they are needed in certain places.

    A couple of further thoughts..

    I’m not fond of data objects starting with DO_ – always the most specific information should be at the front of the name and its inconsistent with the rest of the naming.  I know a lot of the examples are phrased that way, but we shouldn’t be bound by history here – we want a current and future facing best practice.

    As a long time workflow as well as BPM consultant, my preference is for a Verb_Object construct for tasks – it fits better with their purpose and use. e.g. Approve_SoldToParty, Review_Supplier, etc.  That would also align with Request/Response naming – i.e. all the action parts – both dialog/foreground and background – of the BPM process are named the same way.

    Keep going!

    Jocelyn

    (0) 

Leave a Reply