Informatica ETL Deployment Guide

September 17, 2016

Version: Draft

Informatica ETL Deployment Guide

TABLE OF CONTENTS
1.

Overview...................................................................................................................................................................... 3
1.1

2.

Deployment Group Setup............................................................................................................................................. 4

2.1
2.2
2.3
2.4
2.5
2.6

3.

Informatica Version Control and Code Migration..................................................................................................3

General Approach................................................................................................................................................ 4
Group Naming...................................................................................................................................................... 4
Adding Objects to Deployment Groups................................................................................................................5
All Dependencies................................................................................................................................................. 6
Non-reusable........................................................................................................................................................ 6
No Dependencies................................................................................................................................................. 6

Deployment.................................................................................................................................................................. 7
3.1
3.2
3.3
3.4
3.5
3.6

Initial Deployment................................................................................................................................................. 7
Subsequent Deployment...................................................................................................................................... 7
Sequence Generators in Deployment Groups...................................................................................................10
Steps for Deploying via Deployment Groups.....................................................................................................10
Composite Objects............................................................................................................................................. 11
Steps for Copying a Deployment Group.............................................................................................................12

Page 2 of 19

Informatica ETL Deployment Guide

1. Overview
1.1 Informatica Version Control and Code Migration

Informatica has a versioning capability to store multiple versions of Informatica objects. Object versioning
provides the ability to store copies of previous versions of objects in development, track changes to those
objects, and prepare them for deployment to a production environment. A versioned repository assigns
multiple version numbers to versions of the same object. Each time an object is checked in, the repository
increments the version number by one and stores a new version of the object in the repository database. A
repository enabled for versioning can store multiple versions of objects such as sources, targets, mappings,
sessions, workflows, worklets, mapplets, etc.
The Repository Manager provides a way to deploy these versioned objects from one environment to another,
such as migrating a group of objects from the Development environment to SIT. Copying a deployment
group provides the ability to copy objects in a single copy operation from across multiple folders in the source
repository into multiple folders in the target repository. Copying a deployment group also allows one to
specify individual objects to copy, rather than the entire contents of a folder.
Deployment of Informatica Code across environments should be performed via the use of Informaticas
Deployment Groups. This requires that Informaticas Versioning be turned on and active in both the source
and target repositories. While Deployment Groups may be used to move objects within a single repository, it
is recommended that they not be used in that manner. In all but the Development environment all code in
each folder should be migrated SOLELY from its corresponding folder in the prior environment. Objects in a
folder in the SIT environment should only be migrated from the same named folder in the Development
environment. Similarly, objects in the UAT environment should be migrated from the same named folder in
the SIT environment while objects in the Prod environment should be migrated only from the same named
folder in the UAT environment. As such the Development environment is the only environment in which
objects may be copied from one folder to another folder in the same repository. It is recommended that in
such cases the Repository Manager drag/drop interface be used to perform such copies as it provides a
good conflict resolution interface.
This sets up a migration of code where all code changes must originate in the Development environment and
then deploy through SIT and UAT before moving to Production. There are a few exceptions to this general
deployment approach.
Sequence Generators This will be discussed in below.
Schedules Schedules must initially be set up in development and be part of an initial deployment,
but after that the Schedule associated with a workflow should be directly updated in the target
SIT/UAT/Prod environments and handled as an Administrative vs Deployment task.

Page 3 of 19

Informatica ETL Deployment Guide

2. Deployment Group Setup

2.1 General Approach

Deployment Groups may be one of two types: Static or Dynamic. It is recommended that static groups be
used to allow more direct control of deployments. This also allows a deployment set to be fixed and its
objects reviewed without a possibility of those objects changing before the actual deployment of the
Deployment Group takes place. Dynamic groups allow a bit more flexibility in including objects but are more
open to possible unintended changes being deployed.
While One Deployment group in theory could support all migrations between two repositories (say dev and
SIT), it is recommended that two separate Deployment Groups be set up for each separate project in place
on the server. This corresponds to two Deployment Groups for each Folder on the repository, even though
Deployment Groups do allow for migrating objects from multiple folders to multiple folders. These two
Deployment Groups per project will correspond to one Deployment Group for base project releases and one
for Break/Fix deployments.
The way in which the Folders are to be set up in Informatica makes it such that code generally does not
relate to code in other folders. An exception to this will be when downstream IDR pulls are in place and a
change to objects in the base IDR folder needs to be deployed together with corresponding changes to
objects in IDR pull folders. In those cases it makes sense to use one of the project deployment groups as a
combined group to deploy all objects across folders at one time.
If a Shared folder is setup and used for the sharing of objects across environments, special care must be
taken as objects are deployed. Informaticas online help talks through some of the possible issues with such
deployments and should be reviewed before implementing or deploying objects in Shared folders. The
primary issue concerns invalidating non-deployed objects in the target repository requiring either redeployment of those objects or direct manual validation of the objects in the target repository.
2.2 Group Naming

Deployment Groups must be created on the same repository as the objects which will be deployed,
regardless of whether they will be deployed to that same repository or to a separate repository. As such, the
setup of Deployment Groups will be co-located with the source code to be deployed. Also the usage of
Deployment Groups should be reserved strictly to migration of code between environments (Dev to SIT, SIT
to UAT, UAT to Prod and a special case of Prod to UATfor Sequence Generators).
To avoid confusion and make clear the intended usage of a particular Deployment Group the name of the
group should identify the Project Folder, source repository, target repository and project vs Break/Fix usage.
Assuming the initial IDR uses a project folder named IDR this would yield the following Deployment groups
per environment for the IDR folder:
Development
IDR_Dev_to_SIT
IDR_Dev_to_SIT_BF

Page 4 of 19

Informatica ETL Deployment Guide

SIT
IDR_SIT_to_UAT
IDR_SIT_to_UAT_BF
UAT
IDR_UAT_to_Prod
IDR_UAT_to_Prod_BF
Production
IDR_Prod_to_UAT_SEQ
Similarly, assuming a downstream mart project such as SFCDM uses a project folder named SFCDM this
would yield the following Deployment groups per environment for the SFCDM folder:
Development
SFCDM_Dev_to_SIT
SFCDM_Dev_to_SIT_BF
SIT
SFCDM_SIT_to_UAT
SFCDM_SIT_to_UAT_BF
UAT
SFCDM_UAT_to_Prod
SFCDM_UAT_to_Prod_BF
Production
SFCDM_Prod_to_UAT_SEQ

2.3 Adding Objects to Deployment Groups

You manually add or delete objects from a static deployment group. You can add checked in objects to a
static deployment group from the Repository Manager. You cannot add checked out objects to a deployment
group. You can add objects to a deployment group when you view the results of an object query or view the
results of an object history query from the Repository Manager. To add objects from the Query Results or
View History windows, choose Tools-Add to deployment group.
In the Repository Manager, right-click an object in the Navigator or in a detail window, and choose
Versioning-View History. In the View History window, choose Tools-Add to deployment group. To add several
objects to a deployment group, select the group of objects in the Navigator and drag them into the
deployment group.
When you add objects to a static deployment group, you can also add child dependent objects to the
deployment group. You can specify the following conditions for adding child dependencies:
All dependencies - Select to deploy all child dependencies.
Non-reusable - Select to deploy non-reusable dependent child objects.
No dependencies - Select to skip deploying dependent objects.
The following sections will explore each of these options in more detail.
Page 5 of 19

Informatica ETL Deployment Guide

2.4 All Dependencies

When you select All Dependencies, you add all dependent objects to the static deployment group.
Dependent objects can include dependent objects within a workflow or mapping as well as objects that
shortcuts reference and primary key sources where there is a primary key/foreign key relationship.
If you do not choose All Dependencies there is a possibility that several objects that you meant to include in
the deployment group are not included. Lets use the example of a mapping. Lets say you added a new
transformation to a mapping and you want to add that mapping to the deployment group. If you add the
mapping and do not select All Dependencies (or Non-reusable, discussed next), only the mapping shell is
added. All sources, targets and transformations in the mapping are not added to the deployment group.
Only the mapping-level objects such as the mapping description, target load order, parameters and variables,
etc. are included. Therefore, the new transformation that was added to the mapping will not be included
unless either the All Dependencies or Non-reusable option is chosen.
2.5 Non-reusable

A mapping may contain objects that are reusable and objects that are non-reusable. For example, sources
and targets are considered reusable because they are defined outside the mapping and can be used by
many different mappings. Within a mapping there may be expressions, filters, sorters, and other
transformations that apply only within that specific mapping, and are not reusable.
Choosing the Non-reusable option will add all transformations that are local to that mapping only to the
deployment group. Any sources and targets will not be included in the deployment group, as well as any
reusable transformations. Using our earlier example, lets say the new transformation that was added to the
mapping is a reusable transformation. Specifying the Non-reusable option will not add that transformation
to the deployment group. Therefore the migration will not copy over the required objects and the mapping
may be left in an invalid state in the target repository.
2.6 No Dependencies

This will add only the mapping shell as described earlier (mapping description, target load order, mapping
parameters and variables, etc.). No sources, targets or transformations (reusable or not) within the mapping
will be added to the deployment group.

Page 6 of 19

Informatica ETL Deployment Guide

3. Deployment

3.1 Initial Deployment

On an initial deployment of a Workflow or set of Workflows in a folder it is recommended that the Workflow
itself be copied to the Deployment Group and that the All Dependencies option is specified. If no objects are
shared with already deployed Workflows then the Deployment Group will be ready to Copy. If it shares any
objects the procedure for Subsequent Deployments must be followed as well in order to insure objects in the
target are not inadvertently invalidated.

Figure 1 - Dependency for Deployment Group

3.2 Subsequent Deployment

It is recommended that on any change in code that the highest level object which required a change be
deployed with the All Dependencies option specified. If this high level object is not a Workflow it may be
required to add several objects independently to the Deployment Group. Again, in all cases the initial copy to
the deployment group should ALWAYS use the with ALL Dependencies option.
After the initial build of the Deployment Group it is necessary to remove objects from the Deployment Group
which have not changed since being initially deployed. While this is not technically a requirement it does
allow for better auditing in the target environment of which objects have actually undergone a change and
when. Failure to remove these objects will cause the deployment group to deploy all objects with the result
that in the target Repository all objects will appear to have changed, making it difficult to distinguish true
changes from simply re-deployed but unchanged objects.
In order to do this it is necessary to know when the current set of changes began. Any objects with a change
date after that will need to be left in the Deployment Group. Any Re-usable objects which are older than the
set of changes being made and/or which are older than the version currently in the target Repository may be
Page 7 of 19

Informatica ETL Deployment Guide

removed. Note that non-reusable objects copied in as dependencies should never be manually removed
from a Deployment Group due to a potential of invalidating Mappings.
To demonstrate this sample deployment will be worked through. In this case a workflow was initially
deployed which included only one session related to one mapping. In a subsequent deployment a new
mapping was added to this Workflow. As a new mapping it also had a new Session. While new, however,
the mapping had a new/different source but was targeting the same target table as the mapping initially
deployed. As this change required a change in the workflow, and following the rules above, the Deployment
Group was initially populated by copying the Workflow with All Dependencies. The following is the initial
state of the Deployment Group after this build:

Figure 2 - Repository Manager

There are 14 objects in this Deployment Group initially. Note that these are very simple mappings. Often an
copy of a workflow with dependencies to a Deployment Group will yield hundreds or even thousands or
objects.
In order to identify which objects may be safely removed from the Deployment Group the list must be sorted.
Informatica does not allow multi-column sorts. Instead it is necessary to first sort on the secondary sort then
on the primary sort. For the purposes of determining which objects should be removed from the Deployment
Group sort first (secondary sort) on the Last Saved column then on the Reusable column. Note that it is
necessary to sort on each column twice as it will first sort in ascent order and we need new objects on top.
Similarly reusable objects initially sort below non-reusable objects. This yields the following resorted list:

Page 8 of 19

Informatica ETL Deployment Guide

Figure 3 - Repository Manager

The bottom 3 items are non-reusable and must be left in directly, though they may be removed by removing
their parent. In looking at this list there are 3 new reusable objects, all related to the new mapping, its
session and a source for that mapping. There is also a changed reusable object which is the workflow, which
had to change to bring in the new session. The Scheduler as well as the prior mapping, its session and the
target and its sequence generator, as well as the source for the initial mapping are all reusable objects which
did not change. In order to be able to continue to tell in the target repository that these objects have not
changed these objects should be removed from the deployment group. Note that the target is being
removed from the group even though it is in the changed mapping. This is because the target itself hasnt
changed. Removing it from the Group insures that any other mappings which may need this wont be
invalidated just because they were not part of the deployment. If they would not work in this scenario that is
something which should be discovered as part of the initial development testing and the related mappings
updated, causing them to be part of the deployment group.

Figure 4 - Repository Manager

As can be seen removing the mapping removed some of the non-reusable objects as well as they related
only to a reusable object no longer in the deployment group.
Also, of special note is the fact that the default_session_config object has been removed from the
Deployment Group. After the initial deployment of code in a folder, this will always be copied in whenever a
session is changed but must be removed from the Deployment Group. The only exception will be if it is
known that a change to the Default Session settings is being made and has been fully tested. Failure to do
this may cause sessions in the target which are not part of a deployment to fail after a deployment if a default
Page 9 of 19

Informatica ETL Deployment Guide

setting change is not something the mapping/session is set up to accommodate. This default session
configuration is a Folder level setting in Informatica so that all sessions in that folder share the same default
settings unless expressly overridden in a particular session.
3.3 Sequence Generators in Deployment Groups

Copying sequence generators in the past has been a cumbersome and risky process. When copying a
sequence generator from one folder to another there was no option other than to overwrite the entire
sequence generator, including the sequence generator value. Because sequence generators are often used
to generate surrogate primary keys, overwriting this value could cause a duplicate primary key violation when
loading data. The only options were to either not copy sequence generators to the target folder to avoid
overwriting values, or to go back into the sequence generator in the target folder and change the value
manually to what it was before the folder copy.
Deployment groups solve this problem easily, so that copying sequence generators can be done without this
risk. When the Informatica administrator copies a deployment group he is presented a list of options, one of
which is an option to keep or replace the sequence generator value in the target repository.
Sequence Generators will initially migrate the same as all other objects. After the initial deployment of a
Sequence Generator, however, that object need not ever be migrated across environments again unless it is
necessary to change the caching settings of the object. Once deployed and code is run in an environment
the Sequence Generator in each environment will be at a different CurrVal/NextVal setting and uniquely
correspond to its related target database. As such, after the initial deployment a Sequence Generator should
either be left out of deployment groups as described above or should be deployed with the Retain option
select to keep the current CurrVal/NextVal settings in the target. Failure to do this may lead to a series of
Constraint Violations requiring a manual cleanup of Sequence Generator values.
In the event it is necessary to prime the UAT environment to correspond to the Production Environment, a
common event to initialize a UAT cycle, it is necessary to make sure that the Sequence Generators in
Informatica are kept in Sync with the surrogate keys in the database. As such, if a target database instance
is refreshed from another environment, say UAT is Primed from Production, the surrogate keys will be out of
sync with the Sequence Generators in the target. In this event, it is necessary to migrate the Sequence
Generators from the source (Prod) to the Target (UAT) environment in order to keep the code base in sync.
To facilitate this, a reverse environment deployment group should be set up to support the migration of
Sequence Generators from Prod to UAT. When deployed, this group must select the option not to retain the
target Sequence Generator values.
In order to be able to migrate Sequence Generators in this fashion it is required that all Sequence
Generators be created as Re-Usable objects which is not the default setting when a Sequence Generator is
created within a mapping. To facilitate this migration methodology in the event of only a partial database
refresh, the naming of Sequence generators should correspond to the name of their target Table with a
SEQ_ prefix.
3.4 Steps for Deploying via Deployment Groups

Deployment groups can only be copied by Informatica administrators. The information provided in this
section is for informational purposes only. Developers will not have the ability to copy a deployment group,
but it may be useful for them to understand how the copy process works.
The first time you copy an object in a deployment group to the target repository, the wizard creates a new
object in the target repository. The next time you copy the object, the wizard identifies the previously copied
Page 10 of 19

Informatica ETL Deployment Guide

object and replaces it, creating a new version of the object in the target repository. After it creates the new
version, the wizard checks in the object.
As a result, you must be aware of the relationships between objects in the deployment group and the target
repository under the following circumstances:
You copy part of a composite object. When you create a deployment group you can choose to copy all or
part of composite objects. If you choose to deploy part of a composite object, you must ensure that
dependent objects exist in the target folder. This corresponds to how objects are added to the deployment
group.
You copy local and global shortcuts. When you copy a deployment group, the wizard allows you to
reestablish local shortcuts to objects in shared folders. The wizard does not allow you to reestablish global
shortcuts. As a result, you must ensure that the correct shared folders and necessary global shortcuts exist in
the target repository.
Object names in the target repository are different from or conflict with the deployment group object.
An object in the target repository may be a copy of the object in the deployment group, but have a different
name. In this situation, the wizard replaces the copy of the object and creates a new version of the object
with the same name as the deployment group object.
An object in the target repository may also have the same name as an object in the deployment group, but
may not be a copy of the deployment group object. If this naming conflict occurs, the wizard cannot copy the
deployment group object.
The status of the object in the target repository is different from the status of the object in the
deployment group. The status of an object in a deployment group may change after the copy operation
depending on the status of the copy of the object to be replaced.
To protect the integrity of repository metadata, the Copy Deployment Group Wizard does not allow you to
copy a deployment group when objects targeted for replacement are checked out or locked. Before you copy
a deployment group, search for checkouts in the target repository and verify that no deployment target
objects are checked out.
3.5 Composite Objects

A composite object is one that uses other objects. For example, a mapping may use a reusable source,
reusable target, and several non-reusable transformations. Each of these objects is a child dependency of
the mapping.
When you create a deployment group, you can choose to include all dependencies, non-reusable
dependencies, or no dependencies for composite objects. If you choose to copy no dependencies or nonreusable dependencies for a composite object, the wizard uses existing copies of objects in the target
repository for all child dependencies not included in the deployment group. If the wizard cannot locate
necessary dependencies in the target repository, it fails the copy operation.
You must ensure that the dependent objects are also included in the deployment group or already exist in the
target repository. The first time you deploy a group, you must include all dependencies of the composite
object. The next time you deploy the group, you can add all or some object dependencies to the deployment
group.
For example, you edit a mapping variable in a mapping. You want to update the copy of the mapping
currently stored in the production repository. You add the mapping to a deployment group with no
Page 11 of 19

Informatica ETL Deployment Guide

dependencies because you do not want to update any non-reusable or reusable transformations in the
mapping. When you copy the mapping to the production repository, the wizard replaces the current version of
the mapping and associates all existing transformations with the new version.
3.6 Steps for Copying a Deployment Group

Use the Copy Deployment Group Wizard to copy objects in a deployment group. The Copy Deployment
Group Wizard you to perform the following tasks:
Choose deployment folders. You can choose the specific folders in the target repository you want to
deploy.
Apply labels to source and target objects. You can apply labels to the deployment group objects in the
source and target repositories. For example, you may want to apply a label to the source and target objects
that specifies when the source object version was deployed and when the target object version was created.
Move labels. You can move labels from version to version in source and target repositories. For example,
you might want to move a label from the last version to the latest version before you deploy an object. Or,
you might want to deploy an earlier version of an object and apply the latest label to the object.
Clear the static deployment group when you finish copying. You can remove the copied objects from a
static deployment group when you finish copying them into the target repository.
You can copy a deployment group only if the source and target repositories are both enabled for version
control. The repository stores a deployment history for each deployment group.
To copy a deployment group:

Connect to the source and target repositories.

Select the deployment group to copy.

Click and drag or paste the deployment group to the target repository.

The Copy Deployment Group Wizard appears, displaying the folder name and target
repository name.

Page 12 of 19

Informatica ETL Deployment Guide

Figure 5 - Copy Deployment Group

The Copy Deployment Group Wizard dialog box prompts you to select a mode:

Typical. The wizard uses the defaults for shortcuts to local and global shared folders.

Advanced. You can override the defaults for shortcuts to local and global shared
folders. You can choose the shared folders to associate shortcuts. The wizard might have to
determine how the folders are related before establishing shortcuts.

Click Next. The Copy Wizard prompts you for more information based on the content of
the folders and the copy mode you selected.

Page 13 of 19

Informatica ETL Deployment Guide

Figure 6 - Copy Deployment Group - Select Folders

It is possible a few challenge screens may appear if the target folder is out of date. This
is usually the case only on an initial deployment. After that you will be prompted as to
whether you want to clear out the deployment group after the deployment. Unless you need
to retain the deployment group for other purposes you should always select to clear it out.
After this a number of screens prompts will appear. The relevant ones will be shown below.

Page 14 of 19

Informatica ETL Deployment Guide

Figure 7 - Clear Source Deployment Group

Page 15 of 19

Informatica ETL Deployment Guide

Figure 8 - Copy Deployment Group - Sequence Generators

Page 16 of 19

Informatica ETL Deployment Guide

Figure 9 - Copy Deployment Group - Complete Deployment

Page 17 of 19

Informatica ETL Deployment Guide

Figure 10 - Copy Deployment Group

To stop the replacement, click Cancel. The wizard rolls back all changes.

Page 18 of 19

Informatica ETL Deployment Guide

The following table lists the options the requestor of a deployment must specify for the Informatica
administrator to choose when copying a deployment group:

Copy Deployment Group

Prompt

Wizard Dialog Box

Select Deployment Folders

Choose the folders you want to deploy objects to. This should
be specified if you are deploying from one folder in the source to
a different folder in the target. Note that this must be specified
at the folder level, so all objects in the source folder will be
copied to the target folder specified.

Override Deployment Folder

Override the default selections for deployment folders.

Sequence Generators and

Normalizers

Choose to retain current values for Sequence Generator and

Normalizer transformations.

Retain Mapping Variables

Choose to retain persisted values for mapping variables.

Retain Workflow Variable

Persisted Values

Choose to retain persisted values for workflow variables.

Retain Workflow Logs

Choose to retain existing workflow logs in the target folder if you

choose not to copy workflow logs from the source folder.

Retain Server Settings

Choose to retain the assigned PowerCenter Server information

for workflows and sessions configured to run on specific
PowerCenter Servers in a server grid.
Figure 11 - Copy Deployment Group Table

Page 19 of 19