We want to be able to put the wrong data at the end of the queue when something goes wrong, so that the data can be processed all the time without getting jammed, right? Take CRM Inbound Processing as an example. After data is transferred from ERP to CRM, the Middleware framework calls application logic. If an exception occurs in the Application Inbound, If the exception is not handled in the Application, the exception is thrown to the Framework Layer, causing the remaining item in the queue to not be processed and the BDOC to light up. My idea at that time was to abstract the Scenario not supported by the Standard but actually used by the customer into an exception. When the application detects this situation, the application throws the exception, and then outside, The entry to the application catches the exception, type an Error message, and proceed to the next item in the queue.
However, the idea is to treat the issue as a bug in the standard product, i.e. the application code needs to be modified. If the Partner consultant wants to do not change the standard code, it is impossible to complete only writing some BAdI. In addition, if the block size corresponding to the adapter is changed to 1, that is, the size of each queue will be 1. In this way, for example, if there are N material from ERP to CRM, N queues will be generated in CRM, and the size of each queue is 1. This makes the inbound handling of the unique material in each queue separate, but the inbound handling is no longer mass handling. We have not tested how block size =1 affects performance.