henry.nordstrm

Previous post Next post
Currently Being Moderated
Henry Nordström

Getting started with DI Server

Posted by Henry Nordström in henry.nordstrm on May 29, 2006 8:24:56 AM

DI Server has been available to SBO developers ever since SBO 2004 was released. I remember being pretty excited when I first read about DI Server, as it would to enable me to write robust web-based applications with ASP.NET (or whatever other platform I would choose) - something that wasn't really possible to do with plain old DI API.



 

My first encounter with DI Server was somewhat frustrating. I had the service up and running, but it was difficult to figure out how to create my first "Hello World" application on top of it. I was expecting DI Server to provide its own http layer for handling the SOAP requests. It seems that quite many people I've met have had the same misconception. In fact, DI Server is just another COM object that accepts your SOAP requests as string parameters through the Interact method and also returns the response messages as strings. You need to implement your own network access layer on top of it, using whatever protocol you choose. It doesn't necessarily have to be http.



Sure enough, there was the DI Server help file already with the first release. However, the help document pretty much presumes that you already are past the point of making your first successful SOAP call to the DI Server. Luckily, in late 2004 I got a chance to participate a developer meeting in Norway with some SBO Dev Team people from Israel. There I finally got the missing pieces I needed to get up and running with DI Server (thank you, Gali :-). All it took was three simple files with less than 30 lines of script that together provided a quick-and-dirty setup for accessing the DI server from a web browser.



It seems that the product has so far not really taken off as expected among SBO developers. Anyway, my personal experiences have been quite different from what many commentators describe in the SAP Business One discussion forum. Even though there are some limitations and bugs, the product has proven successful for the uses I originally conceived for it. During the past 18 months, I have successfully developed several web applications with ASP.NET, C# and DI Server. The functionality in these applications ranges from business partner data maintenance to booking new sales orders, reviewing order/delivery/invoice history etc. The feedback from customers has been rather positive. How many other ERP vendors provide you with tools to build a production-grade web user interface to some of the key functionalities in about 10 days ?



 

So, what can DI Server do that you couldn't program yourself on top of DI API? First of all, opening a new connection in DI API takes a long time, way too long to be usable in a web application context. DI Server has a connection pool which effectively eliminates this problem (well, you could implement your own connection pool, but is it really worth it?). DI Server is also much more stable in the load conditions of a typical web application (lots of simultaneous requests coming in). Last but not least, DI Server has a nice per-CPU licensing scheme with no per-user limits for the number of active sessions.</p>

 

Installation and configuration gotchas

 

 

Here are some issues I've run into in real-life setups.



    • DI Server is more version-dependent than the other server tools (license service, backup service and messaging service). For instance, it doesn't usually matter which patch level your license server is in SBO 2004. You could easily run SBO 2004 pl 18 with license server from the pl 5 distribution without ever noticing the difference. Because of this, it is quite easy to simply ignore upgrading the server tools when upgrading the databases to a new patch level. Once you start using DI Server, this may cause you some nonnecessary headaches. I once spent several hours trying to figure out why the customer's DI Server installation was returning "General error" for my SOAP requests. The reason turned out to be an out-of-sync version of DI Server.


    • If you are upgrading or making a fresh Server Tools installation on Windows Server 2003, you will need to change the DCOM configuration for SBODI_Server with dcomcnfg. The procedure is explained for License server in SAP Note 833798. The same steps are required for DI Server as well, simply replace "SBOLicense" with "SBODI_Server" and follow the same steps.


    • DI Server does not necessarily have to be installed on the same computer where your SBO Databases are located. If you are developing an application with IIS as your application server, there might be some other conflicting IIS application already in use on the SBO server. Especially Microsoft Sharepoint Server is known to be a troublesome application considering coexistence in an IIS environment.


    • While you probably don't want to use the quick'n'dirty test setup as part of your production application, it is very useful in checking that the infrastructure is properly configured when you are installing your application in a new system environment.


    • Be aware that when DI Server connects to the license server, the address you are using for license server connection will be recorded in the SLIC table in SBO-Common. All SBO clients (including DI Server) that connect to the database will be using this address as default, unless the license server is separately specified (in that case, the SLIC table is once again modified). Because of this, you should avoid such things as using a localhost address (127.0.0.1) for license server, even though that might otherwise seem logical (as DI Server and License server are typically installed on the same machine). To be sure, you should always use the same license server address for all connections. I once spent several hours trying to figure out why DI Server gave me the dreadful -2147023174 error when logging in (even though I had all the DCOM access rights settings done correctly). The reason was that after restarting the DI Server, another DIS application had used a different IP address (public IP address, while I was using a private IP address) for connecting. The problem only occurred when I gave the license server address in the login message. Once I omitted the license server element from the message, I was once again able to log in.


 

Debugging in DI Server

 

 

Once you are able to get the SOAP messages going back and forth between your application and the DI Server, debugging is rather straightforward. To see all the requests and responses in the log file, simply set the log level to "Debug" as instructed in the DI Server help file. After changing the configuration file, you will need to restart the DI Server. Whenever you restart the DI Server, you will need to restart the license service as well. Once your application is in production, you should set the logging level back to "Error", otherwise your log file will quickly become huge.



 

In principle, you could browse the log file with any text editor. However, the trick in log watching is that you are typically most interested in the last entries of the file. A normal text editor would then require you to keep constantly reloading the file to get the latest results. A more sophisticated solution is to use a log tailing tool. Tail is originally a UN*X command, but there are dozens of tail implementations for Windows. Having tried out a whole bunch of them, I personally prefer Baretail . It's compact (186k), it does everything a nice tail application should (word wrapping, color coding etc.) and it's free.</p>

 

The quick'n'dirty test setup

 

 

These three files contain everything you need to start sending messages to your DI Server.



Global.asa contains the code for creating the SBODI_Server.Node object and storing it in the session.

default.htm produces the simple input form for receiving your SOAP requests.
WebSAPManageSoap.asp handles the request sent from default.htm and shows the results received from DI Server.

Simply save the files in your IIS root directory and you're ready to go.

PLEASE NOTE! These files form a "traditional" ASP application, not an ASP.NET application. Support for ASP pages (in addition to ASP.NET) must be selected separately when installing/upgrading the IIS/Application Server component in Windows Server environment.

 

file 1:global.asa

 



Sub Session_OnStart

Session.Timeout = 1

Set Session("SBODI_Server") = Server.CreateObject ("SBODI_Server.Node")

End Sub



Sub Session_OnEnd

set Session("SBODI_Server") = Nothing

End Sub

 

file 2:default.htm

 




















 

file 3:WebSAPManageSoap.asp

 

<p> <%<br> dim requestStr<br> dim outStr<br> dim obj<br> requestStr = Request.Form.Item("HTTP_SOAPACTION")<br> set obj = Session("SBODI_Server")<br> outStr = obj.Interact(requestStr)<br> Response.Write outStr<br> Response.End<br> %></p>

Comments

Actions

Filter Blog

By date:
By tag: