Updating files through BPM

[Former Member]

Hi ,

I have a question where I need to append two files and send them as one file at the receiver by using a coorelation.

Lets Say we have two files -File A and File B both in delete mode .Both are required to be appended and sent as one file ,say AB on the basis of a correlation on a unique value .(e.g division number ).

Acc to the project requirement ,After sending a file A ,If once again a new file of A (e.g A(1)) is updated before the second file B reaches the BPM ; We should append the latest file( A(1) ) with B ,and send it across the receiver .(In this case the result file should become A(1)B ).To achive this we are using a container operation in assign mode and hoping that every new message of same type is overwritten.

But everytime we are updating the file A it opens a new instance of BPM although the coorelation Id is same .

When we send file B with that coorelation ID as of file A,it closes both the instances and creates two file , AB and A(1)B.

We wish that the BPM discards the old file(A) and uses the updated file( A(1) ) in the same instance and puts it on the receiver .

I would like to know if XI behaves in this way only or we are missing something .

Thanks and Regards ,

Neha.

[Former Member · Accepted solution]

Neha,

Which File A or B should trigger a new BPM instance in your requirement?

To answer your question, you might have checked the check box start process in the property of receive step for File A. Hence when a new file comes in, it creates a new BPM instance instead of delivering it to the existing process.

If your requirement is File A should start the process1 and if a new File A1 comes before process1 ends, it should go to process1 else should create process2. I guess you can not achieve this.

Let me know how you proceed with this requirement.

Regards,

Jai Shankar

[henrique_pinto]

Hey Neha,

The problem is that your BPM have only one Receiver step for message A, and since the receiver of instance 1 was already executed when A(1) arrives, it finds no receiver steps with active correlation for A message type, and hence BPE creates a new instance.

Try to redesign it like this:

1. Block step, defining local correlation, with:

1.1. Fork Step, with 2 branches and end condition = 1 branch being completed:

1.1.1. Fork branch 1: Receiver Step for message type B (using correlation);

1.1.2. Fork branch 2: Loop Step (infinite loop, while condition can be 1 = 1), and inside it:

1.1.2.1. Receiver Step for message type A (start process; activating and using correlation);

2. Tranformation Step (multimapping A + B -> AB);

3. Send Step for AB message type;

It will (hopefully) work like this:

- The loop will be running indefinitely receiving all A messages that satisfy the active correlation (always updating the container with the newer one).

- once message B is received, the fork end condition will be satisfied and then the block step will end, deactivating the correlation (which was defined as local correlation in the Block step). Hence the correlation for message A won't be active anymore, and any new messages of message type A which arrive will start a new BPM instance;

- after that, the mapping is executed and you send the message to the receiver.

Of course, you can also start the process and activate the correlation within Receiver for message type B (it depends on your process's requirements). There won't (or at least, shouldn't) be any problems, since you're using a fork step here (so the receiving steps for the different message types are executed in logically parallel threads).

In this case, you don't need a container operation in assign mode, since the receiver step for message A will also update the container for message A with the newer version of message A wich satisfies the correlation.

Give it a shot and let us know the results.

Regards,

Henrique.

[henrique_pinto]

Neha,

I was wrong: there is a flaw in this design, it only works if you are sure that message A will arrive 1st. If message B arrives first, the fork will end without having received any A messages and mapping will fail.

In order to correct this, and since the loop will be running infinitely, just use a simple type container and a container operation in order to have another condition for the end clause of the fork step.

New BPM design:

1. Containers:

1.1. messageA, of abstract interface type, for message A;

1.2. messageB, of abstract interface type, for message B;

<b>1.3. condVar, of simple type (can be integer), for the fork end condition variable.</b>

2. Steps:

2.1. Block step, defining local correlation, with:

<b>2.1.1. Fork Step, with 2 branches, required number of finished branches = 1 and end condition = "condVar = 1":</b>

2.1.1.1. Fork branch 1: Receiver Step for message type B (start process; activating and using correlation);

2.1.1.2. Fork branch 2: Loop Step (infinite loop, while condition can be 1 = 1), and inside it:

2.1.1.2.1. Receiver Step for message type A (start process; activating and using correlation);

<b>2.1.1.2.2. Container Operation Step, assignin condVar with value 1 (make sure to use integer value);</b>

2.2. Tranformation Step (multimapping A + B -> AB);

2.3. Send Step for AB message type;

Now, the end condition of the Fork will occur only if you receive at least one message of type A.

Regards,

Henrique.

[Former Member]

Hi Jai ,

thanks for your prompt reply .As either of the file can approch the BPm first and start the process we cannot assure which file reaches first .thus we are still looking for a feasible solution as of now .

thanks

Neha.