I had come across this requirement in which I had to filter Employees based on department Id. I had configured a file-to-file scenario in which I was sending Employee data that was filtered based on Department Id.The structures, which are used to explain this scenario, are not the same as I faced during real time but symmetrical one.
Before configuring this scenario I was not able to differentiate between the two UDF Execution types i.e. context and queue. During this scenario I had to write a UDF and I came across the different behaviors of the two types. I would like to share my experience with fellow PI consultants.
Scenario: -
I place the file on the ftp. The file adapter picks it up. It contains the employee data and department data. Now the employees are distributed in different departments. Each department has its own ID. Based on the department ID, the employees are segregated. The filtering logic is implemented in message mapping of PI. In message mapping I have defined a UDF. It compares the department key ID (that we send as a filtering key) and the department ID (i.e. in the department structure) and filters the employee data (i.e. from employee structure).
Below are Source and Target structures.
Fig.1
Following is the sender data file, which contains,
Dep_KeyId: To detect which Department Employee should pass.
Department: Consist of Department records.
Employee: Consist of Employees records.
"
Fig.2
As we can see department key-id (i.e. Dep_KeyId) consist of value 4141. Hence, we need to send all those employees that belong to department with ID 4141. The employees Id of employees that belong to department 4141 are 1010, 2020 and 3030.
For IR part create Data type, Message Type, Service Interfaces, Operation Mapping by normal method.
Also configure ID part for file-to-file scenario.
In Message Mapping we can handle required Business Logic. Here Employee node is parent node in target structure; we can handle above-mentioned condition for Employee node by using UDF.
When we create any UDF we can see, three cache execution methods,
1) Value.
2) Context.
3) Queue.
Value is used to process individual input values (i.e. like a single variable) of a field for each function call.
Context and Queue are used to process multiple input values (i.e. like a string array) of a field for each function call.
Let's see how the concept of Context and Queue is differing from each other.
UDF Logic:
Following is the UDF that contains logic to detect which Employee needs to be passed and which Employee needs to be filtered.
UDF logic is mainly dependant on Context Change node. Only by Context Change we can identify how many Employees are there in each Department.
As shown in Fig.5, This UDF requires three inputs.
- dep_Id: Department records. (Context of this input is on Message Header)
- emp_Id: Employee records. (Context of this input is on Department Header)
- depKey_Id: Key id to match with Department Id.
Importance of Context Change node for this requirement:
There are a number of Departments and each Department has number of employees. Therefore employees can be classified on the basis of their department. Context Change node distinguishes employees based on their Department.
As per our structure, we don't have any common key between Department data and Employee data, so we can identify how many Employees are there in a Department, only by detecting Context Change node from Employee data.
Working of UDF in case of Queue and Context:
Queue: When Execution type is Queue the Context Change node is considered data node and UDF can apply logic to check Context Change node. In this case 2nd for loop could properly check the Context Change node and execute both if and else part of logic. Hence output would match as per our requirement. We can see the result in Fig.5
Context: When Execution type is Context the Context Change node is not considered data node. UDF logic doesn't check the Context Change node in 2nd for loop. Logic always executes else part of 2ndloop. It would not match the appropriate result. We can see the result in Fig.8
E.g.
As we have seen in Fig.2 and Fig.5 for,
Department no. 2121 has Employees: 1111,2222 and 3333.
Department no. 3131 has Employees: 4444,5555 and 6666.
Department no. 4141 has Employees: 1010,2020 and 3030.
Suppose we have Department key Id 4141, then to send employees 1010,2020 and 3030 UDF logic works as follows.
- It identifies which Department matches with Department key Id. The number is stored in variable store1. In this case, [2] will be stored in variable.
- The UDF logic identifies Context Change node, which is present in Employee data, and stores the index (i.e. of context change node) in variable store2.
- Then it compares the store1 and store2 variable values. If both values match then that data will pass to target field, else udf logic will suppress the data. In this case, data after 2nd Context Change node will pass.
So the output will look like the one shown in Fig.5
This is possible only if the UDF logic could detect the Context Change node. It could happen in case of Execution type is Queue.
We will see practical example of Queue and Context afterward in this blog.
Fig.3
Case 1: - Execution type = Queue.
Fig.4
Following is the output for UDF in standalone testing.
As the execution type selected is queue, the context change node in the input data is reflected in the udf logic. Hence the department Key Id was properly compared with the department Id and we were able to achieve the desired output.
Fig.5
As we can see the employee data is divided in 3 groups corresponding to three different department Ids. If the context change were not reflected in the udf then the employee data would be in a single group and hence it would not be possible to differentiate the data based on department id.
We can see the Employees with Dep_Id 4141 are displayed in output.
Fig.6
Case 2: - Execution type = Context
Fig.7
In this case the input to the udf will have employees distributed in 3 groups, but as the execution type is context, the context change node will not be reflected in the udf and hence the employee data will not be classified appropriately.
Fig.8
Following is the output file.
Fig.9
Conclusion:
- If we want to apply UDF logic within context then we can use Execution type as Context.
- If we want to apply UDF logic including context change node, then we can use Execution type as a Queue.
Reference:
http://help.sap.com/saphelp_nw04/helpdata/en/f8/2857cbc374da48993c8eb7d3c8c87a/frameset.htm
7 Comments
