Skip to Content

Error handling Requirement PO 7.5

Sep 14, 2017 at 07:56 AM


avatar image

Hello Experts

We have a scenario, wherein, we Input 16 fields of a record to RFC lookup and receive response for 16 fields.

Requirement is, if any of the 16 fields belonging to a record returned 'E' then the message should fail but, we need to scan all the records of the files for 'E' in any of the fields, and output it as a error log file.

We are on PO 7.5.

Any suggestions are welcome :)



10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Best Answer
Patrick Weber Sep 14, 2017 at 08:07 AM

Hi Bhagya,

Why do you need the message to fail? Would it be successful at a later point if you re-processed it e.g. after doing some maintenance in the tables that your RFC lookup is using?

In general you should avoid making messages fail on purpose as failed messages have performance implications to your system. Would it be an option to run the lookup in an enhanced receiver determination and redirect the message to an "Error-Receiver" in case an "E" is coming back? This error scenario could then also take care of creating the log you are looking for.



Show 2 Share
10 |10000 characters needed characters left characters exceeded

Hi Weber

Thank you for your response.

The reason why the message should fail/ should not be processed further is, it contains the financial data, so we do not want partial data to reach ECC. This would affect the postings.

Also, thanks for your suggestion of using Enhanced receiver determination. I would check the feasibility. Meanwhile, if there are any more suggestions, it is highly appreciated.




How do you transfer it to ECC? If you persist it as an IDoc, I would recommend to revisit the error handling process with the users. I have always advised my clients to avoid content validation in the middleware and transfer any data that can be processed into ECC, where specialist users can tackle the content issues. As long as the IDoc is not posted, there is no harm done - you can implement any validation logic you like in the IDoc function module and use the standard IDoc error handling workflow to address the issues you are encountering.