E9.2 Orchestrator naming convention?

vikas_paliwal

Active Member
Hi all

I want to ask what I think is a simple question. Should there be a naming convention for Orchestrations? Are there any known issues that we should be aware of? And what about versions of a specific Orchestration that might get updated in the future with new capabilities...should we have a version number or simply replace the current one with the same name?
 
IMO yes there should be a naming convention for Orchestrations and Orchestration objects/artifacts. The name of our organization is Acme Brick so we put the prefix AB_ on objects (ZZ_ for test/sandbox objects) to help differentiate between custom Orchestrations and delivered. Below is from our internal guide. We are some what new to Orchestrator so I would be interested in feedback.


From Our Internal Guide on naming conventions:

All orchestrator object names should use the following naming guidelines:

[“AB_” or “ZZ_” Prefix]_[Orch Object Abbreviation (see table below)]_[Descriptive Name].
Example: AB_ORCH_ConfirmAllShipmentsOnLoad

The prefix “AB_” will be used for all objects built for actual solutions. The prefix “ZZ_” (or ZZ[initials]_” ex: ZZBGO_) will be used for testing, sandbox, learning, etc.

In general, avoid JDE object names (B4200310, etc.) in the name if possible. In some cases, depending on the object type it may be appropriate to include the object name for example data requests where the object is bound to a single specific JDE object like a table and can’t be changed. The general rule is if the Orchestrator object is bound to a single specific JDE object it is appropriate to use the JDE object name as part of the [Descriptive Name]. If the underlying implementation for the Orchestrator object can be changed or there are multiple objects involved then the [Descriptive Name] should NOT include any JDE object names. For example a custom request that calls a BSFN may in fact call multiple BSFNs or may be changed in the future to call a different BSFN so the Orchestrator name should NOT include any JDE object names.

Orchestration Object Abbreviations

ObjectAbbrExampleAllow JDE Obj
Name
Notes
OrchestrationORCHAB_ORCH_ConfirmAllShipmentsOnLoad
NotificationNOTIFYAB_NOTIFY_CustomerUpdate
Form RequestsFREQAB_FREQ_P01012GetAddressBookInfoY
Data RequestsDREQAB_DREQ_F4211GetSalesOrderLineInfoY
ReportsRPTAB_RPT_R43500CallPOPrintY
WatchlistsWLSTAB_WLST_xxxxxxx
ConnectorsCONNAB_CONN_UpdateLoadStatus
ConnectionsCORCH
API
DB
FTP
AB_API_SendLoadCancelRequestTIP
Leave the description for Connection object blank or duplicate the name in the description. When searching for a Connection object in a Connector the description displays instead of the object name making it very difficult to find the exact Connection Object you are looking for.


CORCH: Connection to an orchestration
API: External Web Service Call (REST, etc.)
DB: Database
FTP: File Transfer Protocol
???: Open API (We need to determine an Abbr for this type)

Note: These are from the Terillium docs. They recommend ORCH for connection to an Orchestration. I preface with a C to distinguish from an actual orchestration. We may want to consider using “C” in from of all of them (CAPI, CDB, etc.).
Custom RequestsCSTMAB_CSTM_UpdateLoadStatusAvoid using BSFN object names. There could be multiple BSFNs used and the underlying BSFN may even change in the future.
MessagesMSGAB_MSG_InvalidSalesOrder
RulesRULEAB_RULE_UserExists
Cross ReferencesXREFAB_XREF_CRMCustomerToAB
WatchlistsWLSTAB_WLST_xxxxxxx
White ListsWLSTAB_WLST_xxxxxx
SchedulesSCHAB_SCH_DailyEvery10Min
 
Thanks for the information Brian. That is very helpful and explains some of the known "tips" that I was not aware of. Appreciate it!!
 
Hi Brian

We use a convention very similar to yours, but replicate the Orchestration descriptive name into the other objects and then extend them. For example:

GL_ORCH_ZTableAutoPost
GL_DATA_ZTableAutoPost_GetCount
GL_REPT_ZTableAutoPost_RunUBE

If we have anything that is system wide then it is prefixed with SYS and may not have the same Descriptive Name, e.g.

SYS_RULE_CountNotZero

Cheers
Jonathan
 
Hi Brian

We use a convention very similar to yours, but replicate the Orchestration descriptive name into the other objects and then extend them. For example:

GL_ORCH_ZTableAutoPost
GL_DATA_ZTableAutoPost_GetCount
GL_REPT_ZTableAutoPost_RunUBE

If we have anything that is system wide then it is prefixed with SYS and may not have the same Descriptive Name, e.g.

SYS_RULE_CountNotZero

Cheers
Jonathan

Sort of like a package name to group related orchestration objects.
 
Hi share my nomenclature to create objects ORCH
For example if the name of our organization is "Stanley" I use the prefix ST

OBJECT NAME
Form RequestsST_FREQ_short description
Data Requests ST_DAT_short description
MessagesST_MSG_short description
ReportsST_SREQ_short description
WatchListST_WLS_short description
ConnectorsST_CONN_short description
ConnectionsST_CON_short description
Rules ST_RUL_short description
Custom requests (Functions)ST_FX_short description
Cross ReferenceST_CRE_short description
Orchestration Object ST_ORCH_short description
Proyect OMW ORCH_INITIALS_YYMMSS_short description


Proyect OMW -> ORCH_INITIALS_YYMMSS_short description (ORCH + 3 prefix name developer + YYMMSS + Short Description)
ORCH_JLE_231117_CreateOR
 
I use our organistion_ORCH_BSFN or APPL name of main object_englishdesc
I always use the Category tab when making ORCHs or ANY UDO component as they are super useful for subgrouping

1700472258539.png
 
The shorter your "required prefixes" the better-- it helps you see the actual name of the component from your Studio Pallette.
 
Back
Top