Professional Documents
Culture Documents
com
Informatica PowerCenter
Naming Convention - Example
Informatica PowerCenter / Naming Convention - Example
About
interface-development.com is devoted to the data integration developer community and provides
solutions since 2003. The website shares real-world expertise and best practices about data integration
topics. It also provides software to support developers reducing their data integration efforts.
Matthias Urech has a proven track record of applying data integration solutions for several companies
across the industry. He played a key role to implement projects in the area of data integration, data
migration, data consolidation, data warehousing and data quality.
Document information
Document conventions
This document uses the following formatting conventions:
< TEXT > Argument you enter as part of the naming convention. The value of the argument is
written in upper case.
< Text > Argument you enter as part of the naming convention. The value of the argument is
written in title case.
< text > Argument you enter as part of the naming convention. The value of the argument is
written in lower case.
{ text } Text inside explains what to do.
[ ] Text or arguments inside are optional.
or Indicates that there is another possibility of using arguments.
Table of Contents
Format
<PROJECT> _ <PRODUCT CODE> [ _ <TYPE> ] [ _ <LOCATION> ] [ _ <VERSION> ]
Argument Description
<PROJECT> Required. Project or system name.
<PRODUCT CODE> Required. Product code or abbreviation of interface.
<TYPE> Optional. Type (IN = inbound interface, OUT = outbound interface).
<LOCATION> Optional. Local extension. Format: ISO-3166 Code (2 characters).
<VERSION> Optional. Version number. Skip if using team based development.
Folder names should NOT contain any special characters ( \ / * ? < > [ ] { } | ). Please pay also special
attention NOT to use periods '.' or spaces ' ' since there is a known limitation in PowerCenter when
using parameter files 1.
Example
DWH_CTM_IN_UK
SAP_BILLING_OUT_US_V2
Format
[ <Version> ]
<Description>
Argument Description
<Version> Optional. Version number. Skip if using team based development.
<Description> Required. Brief description of this version or how this version differs from
previous version.
Example
v1.1
Changed population rules for EOD processing.
1
Informatica Knowledge Base: Article # 9450. Internet: https://my-prod.informatica.com/portal/wps/myportal/ch/ThinkTank
Format
<Server Variable> / <PROJECT> _ <PRODUCT CODE> [ _ <TYPE> ] [ _ <LOCATION> ] /
Argument Description
<Server Variable> Required. Server variable.
<PROJECT> Required. Project or system name.
<PRODUCT CODE> Required. Product code or abbreviation of interface.
<TYPE> Optional. Type (IN = inbound interface, OUT = outbound interface).
<LOCATION> Optional. Local extension. Format: ISO Code (2 characters).
Example
$PMSourceFileDir/DWH_CTM_IN_UK/
$PMWorkflowLogDir/SAP_BILLING_OUT_US/
Format
<DATABASE> _ <SCHEMA>
Argument Description
<DATABASE> Required. Database name.
<SCHEMA> Required. Schema (database user) name.
Connections names should be the same in all environments so that moving mappings from one
environment to another is as easy as possible. Database connections are always written in upper case.
Housekeeping rules need to be put in place in order to limit the number of connections and
maintenance efforts.
Example
DB1DEV_DWH_PROD
DB5DEV_STG_TEST
Format
Database: <SOURCE TABLE> [ _ <qualifying text> ]
File: <FILE_TYPE> _ <SOURCE FILE> [ _ <qualifying text> ]
Argument Description
<SOURCE TABLE> Required. Source table name.
<FILE_TYPE> Required. File type: Flat File = FF_ , Xml File = XML_
<SOURCE FILE> Required. Source file name.
<qualifying text> Optional. Text that describes the content of the source.
Try to keep all sources from the same database in the same ‘database’ folder to avoid any duplication
and possible maintenance errors. Do NOT leave the default server name when importing sources. There
should be a ‘database’ folder for every source type.
Example
Database:
RATE_PLAN
SUBSCRIPTION_prepaid
File:
FF_BILLING_STATEMENTS
XML_SALES_REVENUE_region
Format
<YYYYMMDD>[ <HH24MISS> ]
Argument Description
YYYY Required. Entire year portion of date.
MM Required. Month (01-12).
DD Required. Day of month (01-31).
HH24 Optional. Hour of day (00-23), where 00 is 12AM (midnight).
MI Optional. Minutes (00-59).
SS Optional. Seconds (00-59).
Format
Database: <TARGET TABLE> [ _ <qualifying text> ]
File: <PREFIX> _ <TARGET FILE> [ _ <qualifying text> ]
Argument Description
<TARGET TABLE> Required. Target table name.
<PREFIX> Required. Prefix for files: Flat File = FF_ , Xml File = XML_
<TARGET FILE> Required. Target file name.
<qualifying text> Optional. Text that describes the content of the target.
Example
Database:
ACCOUNTS
REVENUE_region
REVENUE_country
File:
FF_BILLING_SUMMARY
XML_NOTIFICATION_MESSAGE
Format
<YYYYMMDD>[ <HH24MISS> ]
Argument Description
YYYY Required. Entire year portion of date.
MM Required. Month (01-12).
DD Required. Day of month (01-31).
HH24 Optional. Hour of day (00-23), where 00 is 12AM (midnight).
MI Optional. Minutes (00-59).
SS Optional. Seconds (00-59).
Format
re_ <Object>
Argument Description
<Object> Required. Object name.
Reusable objects have a prefix "re_". This makes is easier to differentiate between non-reusable and
reusable objects.
Example
re_sp_calculate_rate_plan
re_exp_error_detection
re_wl_BILLING_CYCLE
re_s_RATE_PLAN
Format
sc_ <Object>
Argument Description
<Object> Required. Object name.
Shortcut objects have a prefix "sc_". This makes is easier to identify objects with dependencies.
Example
sc_mplt_common
Format
z_ <Object> _ <DATE> [ _ <#> ]
Argument Description
<Object> Required. Object name.
<DATE> Required. Date. Format: YYYYMMDD.
<#> Optional. Sequence number.
Orphan object are scored off with prefix "z_", suffix date (date format 'YYYYMMDD') and sequence
number (if more than one objects). Orphan objects should never be supplied in the released product.
Example
z_wf_ODS_CALL_DETAIL_RECORDS_20061231
z_re_wl_102_20070320
z_m_SALE_20050316_1
z_m_SALE_20050316_2
Format
m_ <TARGET TABLE> [ _ <DESCRIPTION> ]
Argument Description
<TARGET TABLE> Required. Primary target table name.
<DESCRIPTION> Optional. Description of action.
Example
m_RATE_PLAN
m_SUBSCRIPTION_PREPAID_ONLY
m_CONTRACT
Format
<Date>. <Developer>. <REQUEST>.
<Description>
Argument Description
<Date> Required. Date.
<Developer > Required. Developer.
<REQUEST> Optional. Change request or incident number.
<Description> Optional. Description of action.
New: Every new mapping will have a line in the mapping comments with the creation date and the
developer, followed by line(s) giving a brief description of what the mapping does.
Change: Every time a mapping is altered a new line will be added at the bottom of the mapping
comments giving the date of the change, the developer who made the change and the change
request or incident number (if applicable). This is then followed by line(s) giving a brief
description of the change(s).
Example
Argument Description
<#> Required. Number of ranks.
<action> Required. Name that describes the process being done.
<COLUMN> Required / Optional. Column name.
<condition> Required. Describes the function of the control to execute a transaction.
<description> Optional. Text that describes the content of the transformation.
<METHOD> Required. Method to be applied: GET, POST or SIMPLE POST
<MODE> Required. Mode to execute SQL scripts: SCRIPT or QUERY
<order> Required. Describes the order direction.
<PROCEDURE> Required. Procedure name.
<qualifying text> Optional. Text that describes the input of the transformation.
<ranking> Required. Ranking type: 'top' or 'bottom'.
<SOURCE> Required. Name of source table or file.
<STORED PROCEDURE> Required. Stored procedure or function name.
<TABLE> Required. Table name or item being obtained by transformation.
<TARGET> Required. Name of target table or file.
<TRANSACTION> Required. Build-in variable of the transaction control transformation.
As a general rule give all transformations names that will assist someone understand the logic of the
mapping. In all cases the default name must be replaced by something more meaningful.
Example
Format Description
Aggregator: { explanation of what transformation does }
Application Source Qualifier: { explanation of the data it is intended to select }
Custom: { explanation of what transformation does }
Expression: { explanation of what transformation does }
External Procedure: { explanation of the external procedure's functionality within the mapping
and what return values are provided }
Filter: { explanation of what the filter criteria are and what they do }
HTTP: { explanation of what method the transformation use and what it does }
Java: { explanation of what transformation does }
Joiner: This Joiner uses <JOINING COLUMNS> from <JOINING TABLES> with
<JOIN TYPE>
Lookup: This Lookup gets <INPUT COLUMN> obtained from <LOOKUP TABLE> to
retrieve the <LOOKUP COLUMN> }
Mapplet: { description of the process that the mapplet carries out }
MQ Source Qualifier: { explanation of the data it is intended to select }
Normalizer: { explanation of what transformation does }
Rank: { explanation of what transformation does }
Router: { explanation that describes the groups and their function }
Sequence Generator: This Sequence Generator provides the { use either 'next' or 'current' }
value for the <COLUMN> on table <TABLE>
Sorter: { explanation contains the port(s) that are being sorted and their sort
direction }
Source Qualifier: { explanation of the data it is intended to select }
SQL: { explanation of what kind of SQL statement is used and what action will
be performed against the database }
Stored Procedure: { explanation of the stored procedure's functionality within the mapping
and what return values are provided }
Transaction Control: { explanation of the process behind the transaction control and the
function of the control to commit or rollback }
Union: { explanation of inputs and indicate what further processing on those
inputs is expected to take place in later transformations in the mapping }
Update Strategy: { explanation of what transformation does and whether it is fixed in its
function or determined by a calculation }
XML Generator: { explanation of what transformation does }
XML Parser: { explanation of what transformation does }
XML Source Qualifier: { explanation of the data it is intended to select }
Argument Description
<INPUT COLUMN> Required. Column name(s) being passed into the lookup and is used as the
lookup criteria
<LOOKUP TABLE> Required. Lookup table name on which the lookup is being performed.
<LOOKUP COLUMN> Required. Lookup column(s) being returned from the lookup. If appropriate,
specify the condition when the lookup is actually executed.
<JOINING COLUMNS> Required. Column name(s) on which the join is done.
<JOIN TABLES> Required. Table names that are being joined.
<JOIN TYPE> Required. Join type.
<COLUMN> Required. Column name.
<TABLE> Required. Table name.
Input ports
Port names should remain the same as the source unless some other action is performed on the port.
In that case, the port has to be prefixed. This will help to immediately identify the ports that are only
being inputted without having to line up the ports with the input checkbox.
Variable ports
For variables inside a transformation, use the prefix 'v_' plus a meaningful name.
Output ports
Output ports are not prefixed since it is intended to be able to use the autolink feature based on names
without having to specify prefix of target transformation. Therefore, output ports should be left as the
target port in the next transformation.
Exceptions
Transformations that are not applicable to the port standards are:
• HTTP: The ports are created when you add ports to the header group on the HTTP tab and are
read-only.
• Normalizer: The ports created in the Normalizer are automatically formatted when the developer
configures it.
• Sequence Generator: the ports are reserved words.
• Stored Procedure and External Procedure: The ports are given by the imported procedure and
are read-only.
• Router: The output ports are automatically created; therefore prefixing the input ports will prefix
the output ports as well. The port names should not have a prefix.
• Sorter, Update Strategy, Transaction Control, and Filter: The ports are always input and
output. There is no need to rename them unless they are prefixed. Prefixed port names should be
removed.
• Union: The group ports are automatically assigned to the input and output; therefore prefixing
with anything is reflected in both the input and output. The port names should not have any
prefix.
• XML Generator and XML Parser: All ports are for input only or for passing through the
transformation. The port names should not have a prefix.
Format
wf_ <PRODUCT CODE> [ _ <DESCRIPTION> ] [ _ <PERIOD> ] [ <#> ]
Argument Description
<PRODUCT CODE> Required. Product code or abbreviation of interface.
<DESCRIPTION> Optional. Text that describes the content of the workflow.
<PERIOD> Optional. Period (D=Daily, W=Weekly, M=Montly, Q=Quarterly, Y=Yearly,
A=Ad_hoc)
<#> Optional. Sequence number outlining period of execution (e.g. D01 = first
day of month 1).
Example
wf_DWH_CTM_IMPORT_M
wf_SAP_BILLING_EXPORT_D01
Format
<Date>. <Developer>. <REQUEST>.
<Description>
Argument Description
<Date> Required. Date.
<Developer > Required. Developer.
<REQUEST> Optional. Change request or incident number.
<Description> Optional. Description of action.
New: Every new workflow will have a line in the workflow comments with the creation date and the
developer, followed by line(s) giving a brief description of what the workflow does.
Change: Every time a workflow is altered a new line will be added at the bottom of the workflow
comments giving the date of the change, the developer who made the change and the change
request or incident number (if applicable). This is then followed by line(s) giving a brief
description of the change(s).
Example
May 12, 2007. Matthias Urech.
Workflow to load order and sales data into DWH Staging Area.
June 26, 2007. Matthias Urech. I 012314
A decision task have been defined so that the sales-order relationship data start loading after the orders
and sales data are loaded.
Format
<Workflow> .log
Argument Description
<Workflow> Required. Workflow name.
Example
wf_DWH_CTM_IMPORT_M.log
Argument Description
<DESCRIPTION> Required. Text that describes the content of the worklet
<#> Required. Load order number.
Example
Non-Reusable Worklet:
wl_SALES
Reusable Worklet:
re_wl_101
Format
<Date>. <Developer>. <REQUEST>.
<Description>
Argument Description
<Date> Required. Date.
<Developer > Required. Developer.
<REQUEST> Optional. Change request or incident number.
<Description> Optional. Description of action.
New: Every new worklet will have a line in the worklet comments with the creation date and the
developer, followed by line(s) giving a brief description of what the worklet does.
Change: Every time a worklet is altered a new line will be added at the bottom of the worklet
comments giving the date of the change, the developer who made the change and the change
request or incident number (if applicable). This is then followed by line(s) giving a brief
description of the change(s).
Example
May 12, 2007. Matthias Urech.
Worklet to load order master data into DWH Staging Area.
June 29, 2007. Matthias Urech. CR 014617
A control task has been defined so that the top-level workflow stops if one of the sessions fails.
Format
Session: s_ <MAPPING>
Session with session overrides: so_ <MAPPING> _ <reason>
Argument Description
<MAPPING> Required. Mapping name (without prefix ‘m_’).
<reason > Required. Reason for using session override.
Reusable Session:
re_s_ADDRESS
Format
<Date>. <Developer>. <REQUEST>.
<Description>
Argument Description
<Date> Required. Date.
<Developer > Required. Developer.
<REQUEST> Optional. Change request or incident number.
<Description> Optional. Description of action.
New: Every new session will have a line in the session comments with the creation date and the
developer, followed by line(s) giving a brief description of what the session does.
Change: Every time a session is altered a new line will be added at the bottom of the session
comments giving the date of the change, the developer who made the change and the change
request or incident number (if applicable). This is then followed by line(s) giving a brief
description of the change(s).
Example
May 12, 2007. Matthias Urech.
Session to load order status data into DWH Staging Area.
June 21, 2007. Matthias Urech. I 054374
Target Commit Interval changed to 1’000’000
Format
Assignment: asgn_ <condition >
Command: cmd_ <description>
Control: ctl_ <description>
Decision: dcn_ <condition>
Email: eml_ <subject>
Event Raise: evtr_ <event> _ <condition>
Event Wait: evtw_ <event> _ <trigger>
Timer: tim_ <description>
Argument Description
<condition> Required. Condition.
<description> Required. Text that describes the content of the worklet
<event> Required. Event.
<subject> Required. Subject of Email.
<trigger> Required. Trigger.
Example
Assignment:
asgn_amount_of_target_success_rows
Command:
cmd_add_file_header
Control:
ctl_fail_parent
Email:
eml_new_source_code_arrived
Event Raise:
evtr_load_completed
Event Wait:
evtw_load_finished
Decision:
dcn_all_sessions_completed
Timer:
tim_start_after_two_hours
Format
<Description>
Argument Description
<Description> Required. Text that describes the content of the task.
Example
Wait Event task that waits for the order and sales session to finish.
Format
<Session> .log
Argument Description
<Session> Required. Session name.
Example
s_RATE_PLAN.log
Format
Session Log File: $PMSessionLogFile
Source File: $InputFile_ < DESCRIPTION >
Target File: $OutputFile_ < DESCRIPTION >
Lookup File: $LookupFile_ < DESCRIPTION >
Reject File: $BadFile_ < DESCRIPTION >
Database Connection: $DBConnection_ < DESCRIPTION >
Argument Description
<DESCRIPTION> Required. Text that describes the content of the session parameter.
Example
$PMSessionLogFile
$InputFile_FF_LOAD_ORDER
$OutputFile_XML_ERROR_NOTIFICATION
$LookupFile_CURRENCY_CODES
$BadFile_RATE_PLAN
$DBConnection_DB1DEV_DWH_PROD
Format
<Workflow> . prm
Argument Description
<Workflow> Required. Workflow name.
Format
Workflow variables:
[ <FOLDER> .WF: <Workflow> ]
Worklet variables:
[ <FOLDER> .WF: <Workflow> .WT: <Worklet> ]
Worklet variables in nested worklets:
[ <FOLDER> .WF: < Workflow > .WT: <Worklet> .WT: <Worklet> ]
Session parameters, plus mapping parameters and variables:
[ <FOLDER> .WF: < Workflow > .ST: <Session> ]
[ <FOLDER> .WF: < Workflow > .WT: <Worklet> .ST: <Session> ]
Argument Description
<FOLDER> Required. Folder name.
<Workflow> Required. Workflow name.
<Worklet> Required. Worklet name.
<Session> Required. Session name.
When you enter values in a parameter file, you must precede the entries with a heading that identifies
the workflow, worklet, or session whose parameters and variables you want to assign. You assign
individual parameters and variables directly below this heading, entering each parameter or variable on
a new line. You can list parameters and variables in any order for each task.
Example
Workflow variables:
[DWH_CTM_IN_UK.WF:wf_DWH_CTM_IMPORT_M]
Worklet variables:
[SAP_BILLING_OUT_US.WF:wf_BILLING_CYCLE_M1.WT:wl_POPULATE_LOOKUPS]
Session parameters, plus mapping parameters and variables:
[CRM_EMPLOYEE_IN.WF:wf_HR_EMPLOYEE_D.WT:wl_MASTER_DATA.ST:s_ORG_CODES]
Format
Use any of the following formats strings for parameters with data type Date/Time:
• MM/DD/YYYY (recommended standard format)
• MM/DD/YYYY HH24:MI:SS
Argument Description
MM Month (1-12).
DD Day of month (1-31).
YYYY Four digits of a year. Do not use this format string if you are passing two-
digit years. Use the RR or YY format string instead.
HH24 Hour of day (0-23), where zero is 12AM (midnight).
MI Minutes (0-59).
SS Seconds (0-59).
Format string ‘MM/DD/RR’ and ‘MM/DD/RR HH24:MI:SS’ are also supported but have not been taken
into consideration for this naming convention.
Format
<project> _ <product code> [ _ <type> ] [ _ <location> ] [ _ <version> ] [ _ <date> ] .rep
Argument Description
<project> Required. Project or system name
<product code> Required. Product code or abbreviation of interface.
<type> Optional. Type (IN = inbound interface, OUT = outbound interface)
<location> Optional. Local extension. Format: ISO-3166 Code (2 characters).
<version> Optional. Version number.
<date> Optional. Date of backup. Date Format: YYYYMMDD.
Repository backup files should NOT contain any special characters ( \ / * ? < > [ ] { } | ). Please pay
also special attention NOT to use periods '.' or spaces ' '.
Example
sap_billing_in_uk_v2_20070702.rep
Format
<PRODUCT CODE>
<Version>
<PowerCenter>
Argument Description
<PRODUCT CODE> Required. Product code or abbreviation of interface.
<Version> Required. Version number.
<PowerCenter> Required. PowerCenter release.
Example
SAP BILLING
Version 2.0
PowerCenter 7.1.3