E9.2 Orchestrator naming convention?

[vikas_paliwal]

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?

 

[BOster]

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

Object	Abbr	Example	Allow JDE Obj Name	Notes
Orchestration	ORCH	AB_ORCH_ConfirmAllShipmentsOnLoad
Notification	NOTIFY	AB_NOTIFY_CustomerUpdate
Form Requests	FREQ	AB_FREQ_P01012GetAddressBookInfo	Y
Data Requests	DREQ	AB_DREQ_F4211GetSalesOrderLineInfo	Y
Reports	RPT	AB_RPT_R43500CallPOPrint	Y
Watchlists	WLST	AB_WLST_xxxxxxx
Connectors	CONN	AB_CONN_UpdateLoadStatus
Connections	CORCH API DB FTP	AB_API_SendLoadCancelRequest		TIP 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 Requests	CSTM	AB_CSTM_UpdateLoadStatus		Avoid using BSFN object names. There could be multiple BSFNs used and the underlying BSFN may even change in the future.
Messages	MSG	AB_MSG_InvalidSalesOrder
Rules	RULE	AB_RULE_UserExists
Cross References	XREF	AB_XREF_CRMCustomerToAB
Watchlists	WLST	AB_WLST_xxxxxxx
White Lists	WLST	AB_WLST_xxxxxx
Schedules	SCH	AB_SCH_DailyEvery10Min

 

[vikas_paliwal]

Thanks for the information Brian. That is very helpful and explains some of the known "tips" that I was not aware of. Appreciate it!!

 

[astradyneuk]

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

 

[BOster]

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.

 

[Lennon2]

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 Requests	ST_FREQ_short description
Data Requests	ST_DAT_short description
Messages	ST_MSG_short description
Reports	ST_SREQ_short description
WatchList	ST_WLS_short description
Connectors	ST_CONN_short description
Connections	ST_CON_short description
Rules	ST_RUL_short description
Custom requests (Functions)	ST_FX_short description
Cross Reference	ST_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

 

[JohnDanter2]

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

 

[DaveWagoner]

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