Skip to Content

We had a requirement to convert IDOC’s in web service without PI (PO). We tried to find out whether SAP provides such solutions. SAP replied to our OSS message saying NO. So we developed our own solution that can convert any IDOC into a web service within minutes. Here I will explain the steps.

Once you set up the system then all programs are reusable to convert any IDOC into web service.

Step 1. Create WSDL for the IDOC basic type or extension type

Step 2. Create server proxy for the WSDL to host the IDOC

 

 

Step 3. Convert the Incoming IDOC and post it

 

/wp-content/uploads/2014/09/20_545321.png

TID 0A6A381E48FE541C4FFF0304 create with IDOC 881704

/wp-content/uploads/2014/09/21_545322.png

IDOC posted in SAP

/wp-content/uploads/2014/09/22_545323.png

Similarly you can convert any IDOC into web service. With ABAP 7.40, SP05 you can further fine tune the code.

To report this post you need to login first.

18 Comments

You must be Logged on to comment or reply to a post.

  1. Jelena Perfiljeva

    Amaresh, thanks for sharing, quite interesting solution. It would never occur to me to use IDoc with a web service, but it’s nice to know nevertheless. I understand it’s been a year already, but could you by any chance elaborate more on what was behind this requirement? Why did you have to have web service with IDoc? Why not have web service call BAPI instead or why not RFC?

    Thank you!

    (0) 
    1. Amaresh Pani Post author

      Hi Jelena – IDOC and BAPI/RFC are used for different purposes, based on requirements. Here are 2 important points.

          IDOC vs BAPI/RFC

      1) Asynchronous vs Synchronous

      2) Out of the box error monitoring, editing & reprocessing tools vs none for BAPI/RFC

      With Regards

      Amaresh Pani

      (0) 
      1. Jelena Perfiljeva

        Yes, I understand the difference between IDoc and other things, but the question was – why did you have to do this with web service? Why didn’t you use a file or RFC connection to create the IDoc?

        Also – even though there are monitoring and reprocessing tools for IDocs with a web service we can build more flexible functionality. The standard one that comes with IDocs has certain limitations.

        (0) 
        1. Amaresh Pani Post author

          Jelena – We have a spring based homegrown private cloud middle-ware, it only uses file & web service adapter for collection & distribution of payloads. File wouldn’t have been a preferable way for single transaction message distribution; also middle-ware needed a real-time response (TID) as a confirmation of IDOC delivery & tracking. Web service makes these things much simpler than file.

          Initially our middle-ware was using a third party adapter that connects to SAP with JCo (RFC) to covert IDOC’s into web service as there was no out of the box solution. By developing this solution we were able to remove the third party adapter.

          We wanted to avoid any custom development around error handling & reprocessing of IDOC’s .

          (0) 
    1. Amaresh Pani Post author

      Hi Carmen – This is designed for single IDOC per transaction. You may need to modify the code for multiple IDOC’s per transaction.

      Amaresh Pani

      (0) 
  2. Frank Scory

    Hi Amaresh,
    good idea, gratulation!

    But i miss the coding of the method GET_DDIC_OBJECT.
    chance to add it to the blog?

    Thanks and BR,
    Frank

    (0) 
  3. John Giesen

    Dear Amaresh,

    Great solution. Exactly what I was looking for.
    Unfortunately you posted twice the coding for the “get_idoc_data” METHOD and there is no coding for  the “get_ddic_object” METHOD.

    Can you please share also the coding for the missing METHOD? That would be great.

    Thanks for sharing this great idea.

    John Giesen
     

    (0) 
  4. Stefan de Boer

    Hi Amaresh,

    Its really a good idea!
    I tried to implement this, but unfortunately the method “get_ddic_object” is missing.
    Can you please send me(email below) the missing code and add it to the blog?

    Thanks!

    Best regards,
    Stefan
    Steef_nh@hotmail.com

    (0) 

Leave a Reply