How to Investigate an Issue from DI Server Logs

An Issue from DI Server Logs

DI Server is the integration framework that provides a SOAP-based messaging system to transfer data to an application. Even though the DI Server is a SOAP-based module, it does not implement SOAP correctly. It is not an HTTP endpoint, but rather it requires COM interfacing to communicate. To fetch data, the DI Server gives you an option to invoke DoQuery and provide an SQL statement which it is going to execute to fetch data, on the other hand for update and insert, they provide DI Server objects to directly update the data to the SAP Server.

Now as it deals heavily with Data, sometimes it gets into a glitch. If you are facing issues on performing your operations through DI Server, or DI Server memory is getting too high in quick time or even the DI Server stops responding in a while, you can look for its logs such that you can find the root cause of the issue happened in the server. In this post, we will cover how you can look at the logs and ensure you find the root cause of any issue.

Do you have multiple systems running? Connect all your business applications under one single platform to automate the business process and increase your productivity and efficiency!


Where Does DI Server Write its Logs?

DI Server stored the log files in a location that is not generally exposed from its interface. But you can open the administrative console to find out the exact location quite easily. Follow the steps mentioned below to find the DI Server logs easily.

Here you have two options:-

The first section provides the URL which is pointing to the log folder. This is the most important location and this is where all the log files are created.

Secondly, you must have noticed that there is a checkbox that is by default checked named “Extended Log”. It is important to check this option to ensure you find correct logging on what has created the issue that you are facing.

Note: In a production environment, it is always recommended to ensure you uncheck the “Extended Log” option when you are not debugging. The Extended log will produce lot of logs into the system with huge I/O operation and disk usage, which might cause the overall application performance issues.

Once you set up the things, wait for the problem to reoccur again, such that you can go to the location to find logs.

Investigating DI Server Logs

Now that we have configured the extended logging, we should go to the location and consider opening the log files. When you just enter the location, you will see multiple logs like the one below :

Here you can see there are multiple files created during the execution of the DI Server. Let us open the B1DI_Server.log file. This is the one that it is currently using. The others are the archive files created when the data size of the server logs increases a specified size.

Open the file B1DI_Server.log in the text editor.

You should use a better text editor to open this file, as you know the file generally contains a huge amount of data, in my case you can see it is almost 212 MB in size. I am trying out NotePad++ to open the file.

After you open, the file you will get to see a lot of Request / Response.

<soapenv:Envelope xmlns:xsi='' xmlns:xsd='' xmlns:soapenv=''>
       <ExecuteSQL xmlns=''>
           <DoQuery><![CDATA[Select CardCode from OCRD where E_Mail='xxx' and CardType='C']]></DoQuery>
23/04/2021 09:50:36 Response (OK)

Now in this log above, there are 3 sections that need attention. The first one is the SessionId, this will indicate what was the sessionID of the request. You can easily “Search and Find”

“Response (Fault)” in this file.

If you search, you will see all the problems that occurred during the execution of the DI Server.

23/04/2021 09:50:43 Request
<?xml version="1.0" encoding="UTF-16"?>
<env:Envelope xmlns:env="">
      <dis:UpdateObject xmlns:dis="">
23/04/2021 09:50:43 Response (Fault)
<?xml version="1.0"?>
<env:Envelope xmlns:env="">
        <env:Text xml:lang="en"> [RDR1.VolUnit][line: 1] , 'Field cannot be updated (ODBC -1029)</env:Text>

Now in this log, the request you can see is an update statement, and it failed with Command Execution failed. You can look at all the logs in this section, mostly all the logs with Selection might generate proper error messages.

Here you can see the error is "Field cannot be updated (ODBC - 1029)". Now if you search this error, you will find what exactly caused this issue.


Now finding an issue coming from DI Server is tricky. If you can pinpoint the exact issue, you could easily solve it. The article, I hope could give you the proper solution to your problem. If you are still not finding the actual cause of it in spite of looking into the log file, feel free to comment, we will try to revert if possible.

Thank you, hope this will help.


APPSeCONNECT is a smart and robust business application integration platform that seamlessly connects all your business applications with each other to streamline operations and facilitate the free flow of data across the platforms. By moving into the region of iPaaS, APPSeCONNECT proves to be a best-in-the-class platform that easily connects systems and automates the business process.

Now, you can easily connect all your business applications under one single platform to automate the business process and increase your productivity and efficiency!



Free Trial / Demo

Try the APPSeCONNECT Integration Platform for 30 Days or request a free demo.
APPSeCONNECT-Horizontal Logo_SVG

Start Your Automation Journey With Pre-Built Connectors.

Get a Demo. Try it Free.

G2 spring badges 2024
we use cookies
We use cookies to personalize your experience. Your visit and usage of this website is subject to acceptance of our Privacy Notice and Cookie Policy.