Wednesday, 26 August 2015

Purging in Informatica


Purging Versions of Objects

You can purge specific versions of objects, or you can purge all versions of objects.

To permanently remove an object version from the repository, you must purge it. You need to check in object versions to purge them. You might want to purge a version if you no longer need it and you want to reduce the size of the repository database.

You can purge multiple versions of an object from the repository at the same time. To completely purge an object from the repository, you must purge all versions. If you purge a version that is not the latest version, the repository keeps a record of the purge in the object history. If you purge the latest version, the repository does not keep a record of the purge.

You can revert to an older version of an object by purging more recent versions. You cannot, however, promote an older version to the current version without purging the more recent versions. For example, you create 12 versions of a mapping. You then determine that you need to use version 10 of the mapping instead of version 12. You can purge versions 11 and 12 to make version 10 the current version.

You use the Repository Manager to purge versions. When you purge versions of objects, you can perform the following tasks:

Purge individual object versions. You can select object versions in the View History window or Query Results window to purge the individual object versions.

Purge versions based on criteria. You can purge versions at the repository, folder, or object level based on purge criteria. This type of purge is called an advanced purge. Use advanced purges to purge deleted or active objects. For deleted objects, you can specify the objects to purge based on the date of deletion. For active objects, you specify the versions to purge based on the version number, the check-in date, or both.

Preview purge results. Preview an advanced purge to view the purge results before you purge objects from the repository. You can view summary or detailed information about the purge.

Purge composite objects. You can purge versions of composite objects, and you can purge versions of dependent objects that make up composite objects. View object dependencies before you purge composite objects. You might get unexpected results if you do not determine the dependent object versions that a purge affects.

The following table shows the Repository Manager commands that you can use to purge versions at the object, folder, or repository level:

Purge Type

Single Object Version

Multiple Object Versions

Versions at Folder Level

Versions at Repository Level

By Object Version

(View History Window)

yes

yes

no

no

By Object Version

(Query Results Window)

yes

yes

no

no

Based on Criteria

(Navigator)

yes

yes

yes

yes

Based on Criteria

(View History Window)

yes

yes

no

no

Based on Criteria

(Query Results window)

yes

yes

no

no

Purging Individual Object Versions

You can select individual versions of objects in the View History window or the Query Results window to purge the versions.

1.

In the Navigator, Select an object and click Versioning > View History.

Or, click Tools > Query, and run a query from the Query Browser.

2.

In the results window, select the object versions to purge.

3.

Click Tools > Purge Object Version.

4.

In the confirmation message, click Yes.

5.

Click OK.

Warning: When you purge an object version, you might invalidate dependent objects.

Purging Versions Based on Criteria

In the Repository Manager, you can purge object versions based on criteria. This type of purge is called an advanced purge. You can purge object versions at the repository, folder, or object level.

When you purge versions based on criteria, you can perform the following tasks:

Purge versions of deleted objects. Purge versions of checked-in deleted objects to permanently remove the versions from the repository. You can purge all checked-in deleted objects, or you can purge objects that were deleted before a specified date. When you purge deleted objects, you purge all versions of the objects.

Purge versions of active objects. Purge specified checked-in versions of active objects. Active objects are undeleted objects and deleted objects that are not checked in. When you purge versions of active objects, you specify the number of versions to keep, a purge cutoff time, or both. If you specify a number of versions to keep and a purge cutoff time, you purge versions that meet both conditions.

Preview versions before purging. Before you purge versions based on criteria, you can preview the purge results to verify that the purge criteria produces the expected results.

Note: When you purge versions based on criteria, you cannot purge a dependent object version if it is used in an unpurged composite object.

The following table describes the options in the Advanced Purge window:

Option

Description

Purge Deleted Objects

Purges versions of checked-in deleted objects. Select All to purge versions of all deleted objects in a repository or folder, or select Older Than to purge versions of objects deleted before an end time. You can specify the end time either as the number of days before the current date or in MM/DD/YYYY HH24:MI:SS format.

Purge Active Objects

Purges specified versions of active objects. Select Older Than the Last n Versions to specify the number of latest checked-in versions to keep. For example, select 6 to purge all versions except the last six checked-in versions. If the object is checked out, you also retain the checked-out version. Select Older Than and specify a number of days or a date and time to purge versions that were checked in before a specified time.

Save Purge List

Output file to save information about purged object versions. Default is disabled.

Summary Only

Saves summary information in the purge output file and displays summary information in purge previews. Disable to view detailed information about each object version. Default is enabled.

The amount of time that the Repository Service takes to purge versions depends on the size of the repository, the number of deleted and old objects, and the composite objects that are affected. For optimal performance, purge at the folder level or use purge criteria to reduce the number of purged object versions. Avoid purging all deleted objects or all older versions at the repository level.

1.

In the Navigator, select a repository to purge versions at the repository level.

Or, select a folder to purge versions from the folder.

You can also select one or more objects to purge objects based on criteria.

Note: You can also use the View History window or the Query Results window to purge based on criteria. Select one or more objects in the window, and click Tools > Advanced Purge.

2.

Click Versioning > Advanced Purge.

Alternatively, right-click the repository or folder and select Advanced Purge, or right-click the selected objects and click Versioning > Advanced Purge.

3.

To purge deleted objects, select Deleted Objects, and then specify whether to purge all deleted objects or objects deleted before an end date.

Or, to purge active objects, select Active Objects, and then specify the versions to keep, the purge cutoff, or both. After you purge an object version, you cannot retrieve it. To ensure that you can revert to past versions, avoid purging all versions of an object.

4.

Optionally, click Save Purge List to create an output file for the purge information.

5.

Optionally, choose to view and save summary information instead of detailed purge information.

6.

Optionally, click Preview to preview the purge.

7.

Click Purge to purge the deleted objects.

Tip: When you use an advanced purge to purge deleted objects, you purge all versions of the objects. To keep recent versions of deleted objects and purge older versions, define a query that returns the deleted objects. Then, use the pmrep PurgeVersion command with the -q option to retrieve the deleted objects and specify the versions to purge.

Previewing Purge Results

Before you purge versions based on criteria, you might want to preview the purge results. When you preview purge results, check the purge criteria before you purge versions from the repository. Also, review the affected object versions to verify that the Repository Service removes the obsolete versions and retains the versions that you want to keep.

When you preview a purge, you can view summary or detailed information about the purge.

To preview a purge, configure the purge criteria for an advanced purge. Choose to view and save summary or detailed information. Then, click Preview.

In the Preview window, you can click Purge to proceed with the purge, or you can click Cancel to close the Preview window without purging. Click Save To File to save the purge preview results to an output file.

Purging Composite Objects

When you purge versions based on criteria, the purged objects might include composite objects such as mappings or workflows. Before you purge a composite object, you need to consider object dependencies. Object dependencies can affect the way that dependent reusable objects are purged.

If you purge a composite object that consists of non-reusable dependent objects, you also purge the non-reusable dependent objects. If you purge a composite object that contains reusable dependent objects, you purge the dependent object versions if they are not used in another composite object.

You cannot purge a version of a dependent object if it is used in a version of a composite object that you do not purge. Also, if you cannot purge a particular version of an object, you cannot purge more recent versions of that object, even if the more recent versions are not used in composite objects.

This section provides two examples that show how dependencies can affect purges of active objects. The first example describes a frequently modified composite object with rarely updated dependent objects. The second example describes a composite object with few versions but frequently modified dependent objects.

Tip: View dependencies before you purge an object to determine if a dependency might affect the versions that you purge.

Example of a Frequently Checked-Out Composite Object

You update the mapping m_Payroll often, and you frequently check it in and out. Five checked-in versions of the mapping exist. You rarely modify the source and target objects in the mapping. There are three checked-in versions of the source and one checked-in version of the target.

At the repository level, you purge versions based on criteria, and you indicate that you want to keep the last two checked-in versions of objects.

The following figure shows the history of versions 1 through 5 of the mapping:

The advanced purge produces the following results:

Object

Purged Versions

Mapping m_Payroll

Versions 1 through 3, assuming that no Session task or other composite object uses m_Payroll.

Source

Version 1. Because you purge the version of m_Payroll that uses source version 1, you also purge that version of the source. The purge keeps the last two checked-in versions of objects, so you do not purge versions 2 and 3 of the source.

Target

None. The purge keeps the last two checked-in versions of objects. Only one checked-in version of the target exists.

Example of a Rarely Checked-Out Composite Object

You rarely check in and check out the mapping m_PhoneList. Two checked-in versions of the mapping exist. However, you frequently check in and out the reusable transformation in the mapping. The transformation is a Filter transformation named FIL_Tr. It has six versions.

At the repository level, you purge versions based on criteria, and you specify that you want to keep only the latest checked-in version of objects.

The following figure shows the history of the mapping and transformation versions:

The advanced purge produces the following results:

Object

Purged Versions

Mapping m_PhoneList

Version 1, assuming that no Session task or other composite object uses m_PhoneList.

Transformation FIL_Tr

Version 1. You do not purge versions 2, 4, 5, and 6 of the transformation, because version 2 of m_PhoneList uses those transformation object versions. You do not purge version 3 of the transformation, because you retain version 2, which is an older version.

Note: If you cannot purge an older version of an object, the Repository Service retains all newer versions of the object during an advanced purge.

Rules and Guidelines for Purging Versions of Objects

Use the following rules and guidelines when you purge versions of objects:

If you purge the latest version of an object and the preceding version has a different name, the preceding version takes the name of purged version. For example, you have the source src_Records. The latest version is named src_Records, but the name of the preceding version in the history is src_RecordsWeekly. If you purge the latest version, the name of the preceding version becomes src_Records.

When you purge an individual version of a dependent object, you render composite objects invalid if they use the dependent object version. Verify object dependencies before purging individual object versions.

In an advanced purge of an active object, you cannot purge a version of a dependent object if it is used in an unpurged version of a composite object.

In an advanced purge of an active object, if you specify a number of versions to keep, you keep the latest checked-in version, even if it was checked in after the purge cutoff time. If the number of versions to keep is greater than the number of object versions, you keep all object versions.









Monday, 24 August 2015

Informatica Mapping Migration from one environment to another

Problem:

Migration of  informatica mapping from Development environment to Test environment.

Mapping uses multiple source shortcuts.When the mapping is migrated in Test environment few shortcuts are not connected to their source qualifiers.???


Answer:

When the migration object like mappings contains any shortcuts to other folders, it's neccessary to first import the dependents from other folders into their respective folders in target repository. And then import the mapping, thus resulting proper relationship between them. If we do not follow this, the objects will be imported but the relationships will be broken.


For 'Why this is so' kind of question - Informatica can export and import objects from only ONE folder to other folder at any given point of time.