Stop BDOCs per User

[former_member182421]

Component	Support Package
BBPCRM	SAPKU70204
SAP_ABAP	SAPKA73105
SAP_BASIS	SAPKB73105
WEBCUIF	SAPK-73105INWEBCUIF
SAP_BW	SAPKW73105

Scenario

Inegration between CRM + PI + SUP + Mobile device, all the integration between CRM and SUP is performed thanks to the SAP CRM Middleware + XIF interfaces( Convert BDoc to Idoc) + PI (Conversion of Idoc to JSON).

The Problem

Mass creation of BPs and Condition each month (until we shut down all the legacy systems...), as we are using the XIF interfaces to replicate the changes from CRM to SUP, when we datatransfer using SXDA+LSMW+XIF from the flat files, the system automatic triggers an BDOC-IDoc to PI, the PI guys can hanlde this volume of data (don't ask me why :twisted: ) so we need to stop the middleware during the data transfer, but, if we stop the middleware we also stop the data syncronization between the Mobile device and CRM, "ok guys, everybody home, we need to do some mass datatransfer".  As I'm not an integration consultant and I don't have time to invest in EDI research I needed to come up with a solution to avoid this behaviour. Stop middleware only for the mass datatransfer but keep it runing for the manual changes done via Webclient or Mobile device.

Approaches

You can stop the replication object using the transaction SMW3_00 - BDoc Type Settings as explains the blog How to stop Particular Bdoc Type replication between CRM & ECC? from narendra.vishwanath but as I mentioned, this would stop the whole replication as is not user dependant  :cry: ,  in our process that's quite critical because people need to keep working during the datatransfer, I found 2 possible workarounds to this:

Approach 1: Using the BADI IDOC_CREATION_CHECK

Pros:

- Standard BADI

- I can filter per IDOC type

Cons:

- The middleware and XIF impacts on the perfromance of the datatransfer

Approach 2: Create a Implicit enhancement spot a the Class CL_SMW_FLOW Method __CHECK_IF_TO_SEND

Pros:

- No performance Impact during the datatransfer, no middleware/XIF is performed.

- You can filter per BDoc type

Cons:

- Create a custom Implicit Enhancement Spot

Solution

I implemented the Approach 2 :twisted: , because having the middleware activated penalize my datatransfer process.

Custom Table and view (transportable content)

I choosed customizing table, because I want to fully buffer the table to impact less possible to the standard middleware send process.

As content is transportable I may need the replication only stop in a particular system and keep it running in the others for develoment/test propose (as you can imagine my user won't create data in production :wink: )

As I already mentioned the impact on the standard should be less as possible.

I also creadted a maintenace view+maintenance program, no secrets here, so I will skip this part, the result maintaned via SM30 looks like this:

Pretty similar to SMW3_00 - BDoc Type Settings, uh? :wink:

Custom enhancement spot on class/method CL_SMW_FLOW->__CHECK_IF_TO_SEND.

Conclusion

I followed the customizing table approach instead of using user parameters (someone could think why I need a custom table when I can solve this via SU3), because the interface XIF for conditions will trigger the standard( enhanced ) class meant to control the middleware flow on commit so the user parameter is not determined via GET PARAMETER ID statement.

Don't forget this is my workaround and is done because I don't have expertise in EDI and PI, I'm sure will be a better and standard solutions, would be cool if someone share them in the comments, feel free to give your opinion! :grin:

Cheers!

Luis