Reading SLG1 logs in a customer program

Question

I'm developing a Gateway and Proxy interface for mutating SAP equipment data. In order to have an idea what's going on with the data that comes in, I've been logging the data using the BAL_* function modules. It works fine, it's been helpful so far.

Eventually though we are going to have end-users that work exclusively via the web front-end and will not have access to the SAP GUI. They cannot use transaction SLG1. As such, I've been asked to create a Gateway entity so that our front-end developers can make a beautiful view for the messages from the log. I've already noticed a handle is created for each log, for example something that looks like 051MjXRE7jMmdAR2X6GWoW. I've made an association between each 'run' and each 'handle'.

I have googled plenty and come by the function group BAL_DSP_LOG_DISPLAY, as well as other BAL_* functions such as BAL_LOG_EXIST and so forth. No matter which of these functions I use, all of them continue to report that the log does not exist (and then in parenthesis, not found in memory). I also haven't really found an example of using these functions outside of first creating it and then immediately showing it afterwards. I'm assuming because the log was just created, the data is already in memory and can just be shown.

However, I can't do this. Most of the calls made to this interface are asynchronous and I cannot sent a message back to the client and there is no SAP GUI. As well, while digging around in the functions and coming back a macro that checks the memory, I've discovered that it apparently does, well nothing.

Does anybody with experience working with this log know how to properly prepare the function group for usage? I'm assuming I have to load this into memory before calling it, but I haven't been able to find one myself that would do something as such.

Answer 1

I've made an association between each 'run' and each 'handle'.

That should not be necessary since you can store your "run ID" as external key (BAL_S_LOG-EXTNUMBER) in the protocol header data - but never mind.

You are right in assuming that the protocol needs to be loaded into memory first - that's what BAL_DB_SEARCH and BAL_DB_LOAD are for. There are plenty of demo programs and documentation available in the package SZAL. You may want to check SBAL_DEMO_05 for this case.

---

Technical explanation of the technique above: The FORM load is used to ensure that the load (byte code) of the function group SBAL is loaded, since otherwise the ASSIGN statement would fail if that wasn't the case. It's just a safeguard against incorrect invocation, not an on-demand loading facility.