Best Practice: Conventions for Object Naming - 8.0

Data Files

any file of any type

used for data i/o

It is recommended to elaborate on all them individually. Base Example:

{yyyymmdd}_{filename}.{ext}

> 20150516_mydatadumpfile.out

> 20150517_mydataloadfile.xml

sample file of any type

to define a schema

These represent files used to define metadata repository schema's.

It is recommended to create these as sample files independent of actual data

files. Base Example:

{yyyymmdd}_{filename}.{ext}

> 20150516_mydatadumpfile.csv

> 20150517_mydataloadfile.json

<department>_<project within department>

or

<workstream>_<project within stream>

Limit project names to 25 characters maximum. Abbreviate the label <project within department> or <project within stream>.

Project name should be in upper case.

Examples:

ACCOUNTING_DATASYNC

ECOMMERCE_FULFILMENT

Project name should be upper case and follow the convention.

MASTER_DATA_<PROJECT NAME>

or

MDM_<PROJECT NAME>

Examples:

MDM_CUSTOMER360

MDM_PRODUCT360

MDM_FINANCE_REF_DATA

Folders are used to group items of a similar category or behavior.

Folder names should be Camel Case, separated by underscores. No whitespace should be allowed. Only use alphanumeric characters, i.e. [Aa..Zz] and [0..9].

A Playpen or Scratchpad should be created in each project under each category of repository items for developers to design temporary jobs. Jobs within the Playpen or Scratchpad can be deleted at any time without any impact. Developers are responsible for deleting their temporary jobs.

• Database Context Group should be created from the Metadata DB Connection definition. This is done by creating a new DB Connection metadata object with the right settings. During the creation of the metadata object, click on the button to Export Context. These database contexts should be left unchanged, i.e. do not rename the context variables or add new context variables to these contexts.
• Additional contexts should be created for project specific requirements. Normally you should limit the number of additional contexts you create. Limit to < 3 new additional contexts per project. For example, you can have a Common context group.

• Database context variables should be left untouched.
• Non-database context group variables should follow Camel Case with the first character in lower case. 

  For example: path, folder, customerId.

• Context variable must be descriptive. 
• Avoid 1 character context variable, for example a, b, c, i, j.

• Job should have meaningful name.
• Limit Job name to less than 50 characters long.

job_<group>_<sequence>_<description>

Where:

<group> is a logical grouping or function of the project, e.g. Staging, SFDC, MDM, Sync. It should be abbreviated and limited to less than 10 alphanumeric characters.

<sequence> is a 3 digit number unique to the job. The Control Job or Master Job will always have a sequence of 000. All other jobs will have a sequence that describes their place in the schedule as shown in the examples below. When multiple jobs can be executed in parallel, make sure that the sequence are different on each of these jobs.

The <sequence> within a group should increment by 10 during initial development to enable additional jobs to be slotted in between in later iterations. The <sequence> provides a sense of the order in which the jobs should be executed within the <group>.

<description> should be informative and give an adequate description of the function of the job.  Description is Camel Case and no white space is allowed.

A Joblet is a code snipped that will be re-used within a job one or more times.

Naming Convention:

jlet_<group>_<sequence>_<description>

Where the <group>, <sequence> and <description> follows the same conventions as for Job above.

A special group name is Global when the joblet being designed is expected to be used across multiple projects.

Joblet descriptions must be concise but adequately described to ensure re-usability.

Each project will consist of zero or more code routines containing Java functions.

Code Routines should only contain static Java functions.

Naming Convention:

cr_<group>_<description>

where:

<group> will be a logical group to identify all code routines that contain similar functions.

<description> will be informative and describe the types of functions present in the package.

globalMap variables enable job specific information to be shared across multiple components. globalMap variables are Camel Case with the first character in lowercase.

If a variable is to be used for storing the values of a field from a schema or input row link, then the name should contain a dot and should follow the same case as the link/schema name and field name.

Component names should be meaningful and should be in Camel Case. Component names should contain alphanumeric characters only and can contain an underscore. Names should also be short (<25 characters) and succinct.

Component link names should be meaningful and should be in Camel Case.