Blog Network Home > Informatica Way > Output Files in Informatica

Output Files in Informatica

by Ramya K on October 14, 2010 in Informatica Way

The Integration Service process generates output files when we run workflows and sessions. By default, the Integration Service logs status and error messages to log event files.

Log event files are binary files that the Log Manager uses to display log events. When we run each session, the Integration Service also creates a reject file. Depending on transformation cache settings and target types, the Integration Service may create additional files as well.
The Integration Service creates the following output files:

Output Files

Output Files

Session Details/logs:

  • When we run a session, the Integration service creates session log file with the load statistics/table names/Error information/threads created etc based on the tracing level that have set in the session properties.
  • We can monitor session details in the session run properties while session running/failed/succeeded.

Workflow Log:

  • Workflow log is available in Workflow Monitor.
  • The Integration Service process creates a workflow log for each workflow it runs.
  • It writes information in the workflow log such as
    • Initialization of processes,
    • Workflow task run information,
    • Errors encountered and
    • Workflows run summary.
  • The Integration Service can also be configured to suppress writing messages to the workflow log file.
  • As with Integration Service logs and session logs, the Integration Service process enters a code number into the workflow log file message along with message text.

Performance Detail File:

  • The Integration Service process generates performance details for session runs.
  • Through the performance details file we can determine where session performance can be improved.
  • Performance details provide transformation-by-transformation information on the flow of data through the session.

Reject Files:

  • By default, the Integration Service process creates a reject file for each target in the session. The reject file contains rows of data that the writer does not write to targets.
  • The writer may reject a row in the following circumstances:
    • It is flagged for reject by an Update Strategy or Custom transformation.
    • It violates a database constraint such as primary key constraint
    • A field in the row was truncated or overflowed
    • The target database is configured to reject truncated or overflowed data.

Note: By default, the Integration Service process saves the reject file in the directory entered for the service process variable $PMBadFileDir in the Workflow Manager, and names the reject file target_table_name.bad. We can view this file name in session level.

  • Open Session – Select any of the target View the options
    • Reject File directory.
    • Reject file name.
  • If you enable row error logging, the Integration Service process does not create a reject file.

Row Error Logs:

  • When we configure a session, we can choose to log row errors in a central location.
  • When a row error occurs, the Integration Service process logs error information that allows to determine the cause and source of the error.
  • The Integration Service process logs information such as source name, row ID, current row data, transformation, timestamp, error code, error message, repository name, folder name, session name, and mapping information.
  • we enable flat file logging, by default, the Integration Service process saves the file in the directory entered for the service process variable $PMBadFileDir in the Workflow Manager.

Recovery Tables Files:

  • The Integration Service process creates recovery tables on the target database system when it runs a session enabled for recovery.
  • When you run a session in recovery mode, the Integration Service process uses information in the recovery tables to complete the session.
  • When the Integration Service process performs recovery, it restores the state of operations to recover the workflow from the point of interruption.
  • The workflow state of operations includes information such as active service requests, completed and running status, workflow variable values, running workflows and sessions, and workflow schedules.

Control File:

  • When we run a session that uses an external loader, the Integration Service process creates a control file and a target flat file.
  • The control file contains information about the target flat file such as data format and loading instructions for the external loader.
  • The control file has an extension of .ctl. The Integration Service process creates the control file and the target flat file in the Integration Service variable directory, $PMTargetFileDir, by default.

Email:

  • We can compose and send email messages by creating an Email task in the Workflow Designer or Task Developer and the Email task can be placed in a workflow, or can be associated it with a session.
  • The Email task allows to automatically communicate information about a workflow or session run to designated recipients.
  • Email tasks in the workflow send email depending on the conditional links connected to the task. For post-session email, we can create two different messages, one to be sent if the session completes successfully, the other if the session fails.
  • We can also use variables to generate information about the session name, status, and total rows loaded.

Indicator File:

  • If we use a flat file as a target, we can configure the Integration Service to create an indicator file for target row type information.
  • For each target row, the indicator file contains a number to indicate whether the row was marked for insert, update, delete, or reject.
  • The Integration Service process names this file target_name.ind and stores it in the Integration Service variable directory, $PMTargetFileDir, by default.

Target or Output File:

  • If the session writes to a target file, the Integration Service process creates the target file based on a file target definition.
  • By default, the Integration Service process names the target file based on the target definition name.
  • If a mapping contains multiple instances of the same target, the Integration Service process names the target files based on the target instance name.
  • The Integration Service process creates this file in the Integration Service variable directory, $PMTargetFileDir, by default.

Cache Files:

  • When the Integration Service process creates memory cache, it also creates cache files. The Integration Service process creates cache files for the following mapping objects:
    • Aggregator transformation
    • Joiner transformation
    • Rank transformation
    • Lookup transformation
    • Sorter transformation
    • XML target
  • By default, the DTM creates the index and data files for Aggregator, Rank, Joiner, and Lookup transformations and XML targets in the directory configured for the $PMCacheDir service process variable.

You might want to read these awesome related posts


Comments on this entry are closed.