Stop BDOCs per User
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).
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 😈 ) 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.
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 😥 , 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
– Standard BADI
– I can filter per IDOC type
– 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
– No performance Impact during the datatransfer, no middleware/XIF is performed.
– You can filter per BDoc type
– Create a custom Implicit Enhancement Spot
I implemented the Approach 2 😈 , 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 😉 )
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? 😉
Custom enhancement spot on class/method CL_SMW_FLOW->__CHECK_IF_TO_SEND.
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! 😀
But the parameter check should be like, if the parameter is maintained for the user, it shouldn't load. Right?. Otherwise(if the parameter is maintained only, load will happen), it 's an extra headache that each user should be maintained with the parameter.
Thanks for your feedback, be aware this approach is for a very specific scenario, the datatransfer, so only 2 users will be maintained, if you want to use it for a long list of users (which I don't recommend) you can replace the user parameter for a customizing custom table or a master data custom table (to avoid the transport layer)
Going to your question, if the parameter is not maintained the BDoc will be send, which is ok, because you don't want to avoid the bdoc generation fo all the users, right? 😉
I think not required. If the parameter is maintained for some user, don't load the changes/updates of that user. If not maintained, load the data. So it won't affect any other users.
yup, is what I meant 🙂
You could for business transaction programmatically supress the creation of BDOCS via an exit, but for business partners, I can't remember if that's available. Conditions, well I can't go there(nor do I want to go there), so yeah. The problem you have is that the solution really is supposed to be "all/nothing" for each destination.. so trying to go inbetween is what you are seing.
The real solution is tell the PI guys to get some bigger/better hardware, as real problem appears that the middleware server you are using is undersized. If I think of another alternative I will let you know, but your options seem reasonable.
It's funny you just mentined conditions, because looks like CL_SMW_FLOW is not trigered by conditions 🙁 I could solve it via solution 1 + solution 2 I'm trying to find where the bdoc CND_M_SUP is validated, because if you disable it via transaction SMW3_00 it works....man...I HATE CRM CONDITIONS.,
Solved, I just updated the Blog.