Email Task In Informatica - Configuration With Example

Email task is used to send emails while running the workflow.Using email task we can get failure and success notifications

Use Email tasks in any of the following locations:

	Session properties. You can configure the session to send email when the session completes or fails.
	Workflow properties. You can configure the workflow to send email when the workflow is interrupted.
	Workflows or worklets. You can include an Email task anywhere in the workflow or worklet to send email based on a condition you define.

To explain this lets take the example of a workflow with two sessions.Session1 and Session2

a)Go to create task and create an Email Task and name it as Test_email

b)Also Enter the following details

• Email User Name : 
• Email subject   :
• Email text:

Email User Name either you can hard code with an email id or give a workflow variable.To give Workflow variable, goto the workflow variable and create a new one to hold email address $$Email_Failure   

 

c)You can give value to workflow variable using parameter File

Emails in the Parameter file

[Sandesh.Workflow:wkfTest]

$$Email_Failure=xyz@mail.com

d)Also make the email task as resuable so that we can use it in multiple sessions. To make it reusable create it using Task Developer.

e)To attach files through Email use the below codes in Email Text

• %a<>To attach file, Absolute path need to be given <>.
• %s Session name
• %e Session status
• %b Session start time
• %c Session completion time
• %i Session elapsed time
• %l Total records loaded
• %r Total records rejected
• %t Target table details
• %m Name of the mapping used in the session
• %n Name of the folder containing the session
• %d Name of the repository containing the session
• %g Attach the session log to the message

1)To add Email Task via session Level

Go to each session and Components level give the On Failure Email as Test_Email, also give Type as Reusable and Save.This will trigger the email for Failure

2)To add Email Task via Workflow level

Goto workflow and in the Suspension Email enter the Email task name, Also give Suspend on Error and save

FORWARDING REJECTED ROWS property in an Update Strategy transformation & bad file structure

  

When we use the update strategy transformation we have the option to reject the row based on a criteria. We usually use DECODE or IIF to specify the criteria for rejecting the row[Treat Source Row should be selected as Data Driven at the session level if update startegy is used ]

IIF( ( RESIDENT_SK=0), DD_REJECT, DD_UPDATE )

The following table lists the constants for each database operation and their numeric equivalent:

Insert	DD_INSERT (Numeric Value 0)
Update	DD_UPDATE (Numeric Value 1)
Delete	DD_DELETE (Numeric Value 2)
Reject	DD_REJECT (Numeric Value 3)

Now coming to the Forwarding Rejected Row Option in update strategy, this option is used to forward the rejected rows into the bad file which we define at session level. If you disable this option, the rejected records won't be available in the bad file (reject file).

However the rejected rows will be available in session log (Normal logging level) even though the forwarding rejected row option is enabled\disabled.

These records in the reject file help us to understand the reason for rejection and validate the records not satisfying the business requirement. This helps to change the input data the next time we load the target

Bad file - 

Bad Files are often termed as Reject Files that holds the data for the entire row, which is rejected by the Target while writing. Whenever a Session is created with a Target, Reject Files (Bad Files) are also created along with it.

Why are bad files created  - 

Bad Files always extends the scope of error tracking. It helps you to get the record and the values which got rejected. And with the help of the information available in the Session Log, you can perform some analysis to track the exact error and take steps to correct it accordingly. You might also use the Bad File to send it to the users as an attachment with some modification to the record using Scripting. 

Where are the bad files created - 

By default, the Integration Service creates reject files in the $PMBadFileDir process variable directory. You need to explicitly define/override the value if you want to store the bad files in some other directory.

Structure of Informatica Bad Files or Reject Files

There are two types of Indicators in the reject file. One is the  Row Indicator and the other is the Column Indicator.

1. Row Indicators - 

• The first column in each row of the reject file is the row indicator.
• The row indicator defines whether the row was marked for insert, update, delete, or reject.

List of Values of Row Indicators:

Row Indicator	Indicator Significance	Rejected By
0	Insert	Writer or target
1	Update	Writer or target
2	Delete	Writer or target
3	Reject	Writer
4	Rolled-back insert	Writer
5	Rolled-back update	Writer
6	Rolled-back delete	Writer
7	Committed insert	Writer
8	Committed update	Writer
9	Committed delete	Writer

2. Column indicator

• Column indicators appear after every column of data.
• The column indicator defines whether the column contains valid, overflow, null, or truncated data. 

Column Indicator	Type of data	Writer Treats As
D	Valid data.	Good data. Writer passes it to the target database. The target accepts it unless a database error occurs, such as finding a duplicate key.
O	Overflow. Numeric data exceeded the specified precision or scale for the column.	Bad data, if you configured the mapping target to reject overflow or truncated data.
N	Null. The column contains a null value.	Good data. Writer passes it to the target, which rejects it if the target database does not accept null values.
T	Truncated. String data exceeded a specified precision for the column, so the Integration Service truncated it.	Bad data, if you configured the mapping target to reject overflow or truncated data.

Event wait and Event Raise tasks in informatica

There are different types of tasks in Informatica Workflow manager which we use while running a workflow.
I have listed it below. 

Tasks	Description
Assignment	Used to assign a value to a workflow variable
Command	Used to run a shell command during the workflow
Control	Used to stop or abort the workflow
Decision	Tells a condition to evaluate
Email	Used to send email during the workflow
Event-Raise	Notifies the Event-Wait task that an event has occurred
Event-Wait	It waits for the event to completed in order to start the next task
Session	Used to run the mapping created in Designer buy linking to session
Timer	It waits for a already timed event to start

WORKING WITH EVENT TASKS

We can define events in the workflow to specify the sequence of task execution.

Use the following tasks to use events in the workflow:

v    Event-Wait task. The Event-Wait task waits for an event to occur. Once the event triggers, the Integration Service continues executing the rest of the workflow.

Types of Events:

·        Pre-defined event: A pre-defined event is a file-watch event. This event waits for a specified file to arrive at a given location or directory.

Let us try to understand it with an example. Suppose you wanted to wait for a file to arrive in a directory while keeping the workflow on running mode. Once the file arrives in the directory the mapping session should automatically be kicked off to load the data into target. In this case we can use event wait task as file watcher event. PFB screenshot of the same.

·        User-defined event: A user-defined event is a sequence of tasks in the Workflow. We create events and then raise them as per need. In this case we first raise a user defined event and then configure the event wait which will wait for user defined event to occur and triggers the next session in the workflow

    EVENT RAISE: Event-Raise task represents a user-defined event. We use this task to raise a user defined event.

    EVENT WAIT: Event-Wait task waits for a file watcher event or user defined event to occur before executing the next session in the workflow.