ccBPM RFC lookup

[steve_coombes]

Hello,

I have a function module that I use to perform a sequence check for incoming requests to PI :

1. The message mapping calls the sequence check RFC, with a value taken from the message (or filename), and the next value expected.
2. If the value from the current message equals the next value expected after the last message, then processing continues. If it is not the expected message, then an exception is thrown.

For example, a message might contain a date range, 1 January to 31 January. The mapping sends :

     Current value                : 1 January

     Next value expected     : 1 February

The message mapping is contained in an Integration Process.

This usually works, but I find that if a file is submitted out of sequence and the check fails, then other sequence checks that are taking place at the same time for other messages may also fail when they should be successful.

The sequence data table is updated with the current file details as expected, but an error is thrown to say that the next file is expected.

I have only recently started using this method of checking the sequence, so cannot say if the error occurs when used outside an Integration Process.

Does anyone have any ideas what might cause the problem, or perhaps suggest an alternative way to perform the sequence check? Is it possible to look at a log of RFC requests to see if any have been duplicated?

Kind regards

Steve

[Former Member]

Hello Steve,

have you considered Quality of Service "Exactly-Once-In-Order"? To me it looks like you try to rebuild a functionality that SAP delivers by default.

If I misunderstand you it might be helpful to explain the scenario a bit better. What is the requirement? Which system sends to which system?

Regards,

Jörg

[steve_coombes]

Hello Jörg

Sorry - I don't think I explained it very well at all.

Background

We have a number of users who export files from their finance systems (each system is of the same type but separate). The files are copied into a folder where they are picked up by PI.

The problem is that the users are not very good at copying files. They miss files, copy the same one more than once, or copy something totally irrelevant. One of them even copied a Powerpoint presentation of their skiing holiday pictures.

So I read a value from the file contents, for example a date, and compare it with a known value to ensure the file is expected. In this way no files should be missed, and none processed more than once. Remember, the user may well import the same file again by mistake on another occasion.

Problem

The RFC call that I use to perform this validation check isn't working as I expected when a file is out of sequence. The check fails correctly for the file that is out of sequence. But it also sometimes fails for other files that are in sequence, but are processed at the same time as the one that fails.

I assumed that RFC's are stateless and thread-safe. But something seems to occur when the RFC returns an out of sequence flag, so that the same RFC call in another instance of an Integration Process also returns an out of sequence flag when it shouldn't.

I was wondering what my options are to investigate further. It is a Production system so I don't want to debug the function module.

Kind regards

Steve

[Former Member]

Hello Steve,

can you reproduce the error in your test systems? Is your RFC changing data in the ABAP system? My suspicion is that one process sets a lock on the table and concurrent accesses then fail. PI is usually thread-safe, but the lock on an ABAP database is surely not. If you think this is a possible scenario you could test that by inserting a break-point in your test system, hold one (erroneous) call there and then send in another (valid) file.

Maybe one step back, can you see the error message the RFCs deliver that should not fail? Maybe the error message gives you a hint to the real problem. You should be able to see that in the message trace or in audit log.

If you don't, same procedure: Try to reproduce the error in a test system and watch closely what exactly happens.

I haven't done that for a file adapter, but I believe that you could also solve concurrencies by EOIO. If your performance requirements allow that, you could avoid the problem this way.

Regards,

Jörg

[steve_coombes]

Hello Jörg

Thanks for your suggestions. That gives me a few leads to follow.

Kind regards

Steve