Skip to Content
author's profile photo Former Member
Former Member

DI Server API - is it ready for production use?

Hi all,

I have been doing some work with the DI Server API over the last couple of weeks and have been generally struggling! I am having lots of problems which suggest, to me at least, that it's not yet ready for production use and was perhaps rushed to release.

So does anyone else have any experiance / thoughts on using the DI Server in anger? Any tips that might make the whole thing palatable?

Some of the issues I have encountered follow, apologies if this seems like a bile blog, it's been a frustrating couple of weeks :-

1. The DI Server uses SOAP formatted messages for interaction, this suggests that creating a web service should be trivial, however this just not the case. The sample asp files that have been made available to gain access to the API do not permit the use of standard web service API's (especially in the Java world). I can code a more suitably replacement (i.e. something that accepts SOAP messages as required for web services), however as there is no WSDL file, coding the SOAP client would have to be done by hand, which, at best, is slow and error prone.

2. The XML schemas that are shipped with the API are not accurate, I have tried to use these to generate XML bindings using JAXB (XML -> Java objects), which makes the parsing exercise trivial, only to find that the binding fails as the schema published does not match the XML returned.

3. The documentation is incomplete, and in some places inaccurate.

I know that all these issues are summountable, but I just want to get on with accessing the information stored with SBO and actually meeting business driven requirements. Using a DI API like interface exposed as a proper web service with a WDSL file would allow me to do that.

Regards

Darren.

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Best Answer
    Posted on Feb 02, 2005 at 11:21 AM

    Hi Darren,

    I apologize for the inconviniencies you encountered around DI Server.

    You are right that no WSDL file is shipped with DI Server. Sorry for that.

    Of course it is somehow natural to have such a thing, but it is not there and currently you have to implement it on your own...

    So, basically it depends on the size of your requirements for data level integration + potential timelines whether or not DI Server - as it is right now - is the way for you to go.

    XML schemas have partially been corrected with some patch (some now dating from Jan, 7th)...

    If there are still inconsistencies between the schemas provided and the XML returned, please report these bugs on SAP Service Marketplace.

    Apparently other developers have managed to use DI Server for their needs; maybe they could share some more (and hopefully better 😉) experiences.

    Regards,

    Frank

    PS: It does not matter where you find the bug: SDK, SDK samples or SDK documentation. Please report it so that it can be fixed.

    PPS: Currently only a very few non-functional messages (just the usual suspects: installation, connect, documentation) have been reported via SAP Service Marketplace...

    Message was edited by: Frank Moebius

    Add a comment
    10|10000 characters needed characters exceeded

    • Hi Darren,

      I have no information regarding WSDL currently. I just know that some partners - with just a small number of objects needed - devloped a webservice using DI Server by themselves...

      Re connection SUN - SAP Business One a colleague gave me the following hint (I am far from being an expert for this 😉):

      If someone wants to access B1 from SUN can send directly B1 SOAP messages to a simple receiver on the windows machine that routes them back to DI server - and viceversa sends back the SOAP responses from DI server to the client ...

      HTH,

      Frank

      P.P.S. No, apparently this could be improved somewhat ("documentation" fixes seem not to be included in the info file?). Thanks for the remark!

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.