Skip to main content

Repository Items

Repository Item Naming Convention
Folder

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.

Contexts Contexts are group of variables defined for various environment.
  • 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.
Context Variable
  • 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 A Job contains the logic of the design.
  • Job should have meaningful name.
  • Limit Job name to less than 50 characters long.
Naming Convention:

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.

Examples:
  • job_Report_000_controlJob
  • job_Report_010_fileReception
  • job_Staging_000_controlJob
  • job_Staging_010_stageTheFinanceFile
  • job_SFDC_000_controlJob
  • job_SFDC_010_checkPickListValues
  • job_SFDC_020_insertAccountRecord
Joblet

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.

Examples:
  • jlet_Global_000_logErrorToFile
  • jlet_SFDC_000_establishConnection
  • jlet_SFDC_010_closeConnection
Code Routines

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.

Examples:
  • cr_dwh_dateValidation
  • cr_dwh_arrayHandler
  • cr_dwh_textFormat 
globalMap Variables

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.

Examples:
  • customerNumber
  • countOfInputRecords
  • customer.id (customer is the name of the input row, and id is the field name)
  • transaction.transaction_code (transaction is the name of the input row, and transactioncode is the field name)
Components and Links

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.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!