SAP BPM Best Practice: Naming Convection for Modeling of BPM
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:
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 |
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
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
Hi srinivas sistu,
Thanks for the comments sent to me offline. I have the the changes as suggested.
Cheers
Piyas
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
Hi Jocelyn Dart,
Thanks For the suggestion.
I have tried to add your recommendation in the document.
Cheers
Piyas