How to move mappings from Development folder to Production folder in Informatica

We can move the objects from Development folder to Production folder in Informatica by using any of the two methods.Before making any changes to the Production folder make sure you take the back up of all the objects.

Export and import

    Export the mappings that you want to move from the DEV folder and save those as XML in some folder.
    Take the back up of the Production mappings before replacing
    Import these XML into Production Folder
    Save the mappings

But when you are doing these we need to check the below things
1.We need to check the Replace check box in case the source or target is already present in the folder
2. For other reusable transformations such as source shortcuts, target shortcuts or any other transformations (Sequence Generator, Lookup etc) choose Reuse (not replace)
3. On Global copy options, in conflict resolution wizard, select (or mark) Retain Sequence Generator, Normalizer or XML key current values.

Direct Migration :

IF the Development and Production are in separate repositories then go to the Repository Manager and then connect to the development Repository.Then go to the Production repository and open that too.Then you can drag and drop all the folders from Dev to Production.
Note:
Problem might come when we export and import objects separately i.e. mapping, workflow etc. The big problems is shortcuts. In this case
1.Open Development folder from Repository Manger
2.Select only the workflows related to the mapping from the repository manager and export only the workflow XML. This will take all the associated objects (mappings, sessions, etc.) with the workflows.
3.Import from this single file into your Prod Environment.
This will import and export everything regarding a mapping.




How to Delete a duplicate records using Dynamic lookup cache
1. Objective:

To filter duplicate records in a source, solution described below uses a lookup transformation with
dynamic cache enabled. System generated port NewLookupRow is used to identify new records.

2. Source definitions:

Source is EMP table as shown in figure 1. This can be a flat file source also depending on the
requirement.


Figure 1: Relational source EMP (Oracle)

3. Target definitions:

Target is copy of source i.e. another table with same structure as of source. All distinct records found
in source table will be inserted into target table EMP_TARGET. All duplicate records will be discarded.

4. Mapping:

Figure 2 shows the mapping designed to filter duplicate records in source.

                             Figure 2: Mapping logic

4.1 Transformations used
LK_target
Lookup transformation with dynamic cache properties enabled is used to identify if the incoming
record already exists in target. If yes then value of NewLookupRow port will be 0. If incoming record is



Lookup condition is EMPNO=IN_EMPNO. This condition depends on the key to identify duplicate
records. In my example I am just looking for duplicate empno. Dynamic Lookup Cache property for
this lookup transformation is enabled.
FL_new_rows
This filter passes only new rows to the target. Filter condition is NewLookupRow = 1.



We get the unique records in Target table.
FACT LESS FACT TABLE



We know that fact table is a collection of many facts and measures having multiple keys joined with one or more dimension tables. Facts contain both numeric and additive fields. But factless fact table are different from all these.
A factless fact table is fact table that does not contain fact. They contain only dimensional keys and it captures events that happen only at information level but not included in the calculations level. just an information about an event that happen over a period.
A factless fact table captures the many-to-many relationships between dimensions, but contains no numeric or textual facts. They are often used to record events or coverage information. Common examples of factless fact tables include:
  • Identifying product promotion events (to determine promoted products that didn’t sell)
  • Tracking student attendance or registration events
  • Tracking insurance-related accident events
  • Identifying building, facility, and equipment schedules for a hospital or university
Factless fact tables are used for tracking a process or collecting stats. They are called so because, the fact table does not have aggregate table numeric values or information. There are two types of factless fact tables: those that describe events, and those that describe conditions. Both may play important roles in your dimensional models.
Factless fact tables for events:
The first type of factless fact table is a table that records an event. Many event-tracking tables in dimensional data warehouses turn out to be factless. Sometimes there seem to be no facts associated with an important business process. Events or activities occur that you wish to track, but you find no measurements. In situations like this, build a standard transaction-grained fact table that contains no facts.
For eg.
The above fact is used to capture the leave taken by an employee. Whenever an employee takes leave a record is created with the dimensions. Using the fact FACT_LEAVE we can answer many questions like
  • Number of leaves taken by an employee
  • The type of leave an employee takes
  • Details of the employee who took leave
Factless fact tables for conditions
Factless fact tables are also used to model conditions or other important relationships among dimensions. In these cases, there are no clear transactions or events. It is used to support negative analysis report. For example a Store that did not sell a product for a given period.  To produce such report, you need to have a fact table to capture all the possible combinations.  You can then figure out what is missing.
For eg:
fact_promo gives the information about the products which have promotions but still did not sell

This fact answers the below questions:
  • To find out products that have promotions.
  • To find out products that have promotion that sell.
  • The list of products that have promotion but did not sell.
This kind of factless fact table is used to track conditions, coverage or eligibility.  In Kimball terminology, it is called a “coverage table.”
Commit Interval




A commit interval is the interval at which the server commits data to relational targets during a session.
Three types of Commit Intervals:
Target based commit.
Source based commit.
User defined Commit.

If you use in Transaction control Transformation that time the commit type is automatically convert to User defined commit.
Default commit interval is Target.
(a) Target based commit
1.    Server commits data based on the no of target rows and the key constraints on the target table. The commit point also depends on the buffer block size and the commit interval.
2.    During a session, the server continues to fill the writer buffer, after it reaches the commit interval. When the buffer block is full, the Informatica server issues a commit command. As a result, the amount of data committed at the commit point generally exceeds the commit interval.
3.    The server commits data to each target based on primary –foreign key constraints.
(b) Source based commit
1.    Server commits data based on the number of source rows. The commit point is the commit interval you configure in the session properties.
2.    During a session, the server commits data to the target based on the number of rows from an active source in a single pipeline. The rows are referred to as source rows.
3.    A pipeline consists of a source qualifier and all the transformations and targets that receive data from source qualifier.
4.    Although the Filter, Router and Update Strategy transformations are active transformations, the server does not use them as active sources in a source based commit session.
5.    When a server runs a session, it identifies the active source for each pipeline in the mapping. The server generates a commit row from the active source at every commit interval.
6.    When each target in the pipeline receives the commit rows the server performs the commit.