# 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,, 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. |