Skip to Content
Author's profile photo Luís Pérez Grau

Stop BDOCs per User

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 😈 ) 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  😥 ,  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 😈 , because having the middleware activated penalize my datatransfer process.

Custom Table and view (transportable content)

tabledef.JPG

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

table.JPG

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 😉 )

tabletech.JPG

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:

viewmaintenance.JPG

Pretty similar to SMW3_00 – BDoc Type Settings, uh? 😉

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

source.JPG

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! 😀

Cheers!

Luis

Assigned Tags

      7 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Faisal PC
      Faisal PC

      Hi Luiz,

      Nice one.

      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,

      Faisal

      Author's profile photo Luís Pérez Grau
      Luís Pérez Grau
      Blog Post Author

      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? 😉

      Cheers!

      Luis

      Author's profile photo Faisal PC
      Faisal PC

      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.

      Thanks,

      Faisal

      Author's profile photo Luís Pérez Grau
      Luís Pérez Grau
      Blog Post Author

      yup, is what I meant 🙂

      Cheers!

      Luis

      Author's profile photo Stephen Johannes
      Stephen Johannes

      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.

      Take care,

      Stephen

      Author's profile photo Luís Pérez Grau
      Luís Pérez Grau
      Blog Post Author

      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.,

      Cheers!

      Luis

      Author's profile photo Luís Pérez Grau
      Luís Pérez Grau
      Blog Post Author

      Solved, I just updated the Blog.