I was reading Jason Le's recent post about XML Logging and I realized the problem statement he was describing was intimately familiar to me because it is something I have been dealing with over the years and have evolved a solution for it. I say evolved because it has gone though so many iterations by this point I am not sure where to begin. So let me start with a verbal explanation, and then I will get into the details.
I built an eScript Logging Service back in the day to help with tracing processing through custom script. This was written out to a text file in the file system. I don't recall the sequence of events after that but at some point I added an XML logging utility to this so that the XML files would be written to the file system as well. This was initially an explicit call to a business service within the integration WF to pass an XML Property Set so it could be written out. I then moved to a client which was using a business service to create custom SOAP headers so I modified the logging service so that it could be called as a custom filtering service itself. This allowed the exact payload to be captured as it was leaving/returning to the Siebel application.
At some point I ended up on a client that had UNIX Application servers, needed me to do production support post go-live AND was very restrictive about granting access to the production file system. Rather than deal with the UNIX and access issues, I opted to modify the service so it could operate in two modes. When using a thick client, it would continue to write all information out to the local file system as defined by the SIEBEL_LOG_DIR environment variable. But I allowed thin client users to output logging data to a new set of custom tables. Basically when a user logs in, a session record is created. All escript logging data is written out to a 1:M detail table in buffered chunks to minimize performance hits. XML Logging does the same (though in a slightly different way). Each detail record has the opportunity to store a row id which allows a session to be linked to a particular record that was logged, like an Order Id. This allows for audit views to be created which show all the user sessions with logging information tied to a particular record.
The other problem I needed to solve was that when an error occurs, Siebel rolls back transactions. Therefore all interfaces use the EAI Transaction Service and I have modified this service to set a flag so that when in a transaction, all XML payloads are stored in memory until the transaction is either aborted or committed, at which point all the messages are written to the DB in the order they were executed.
To view logging information, whether XML or escript, requires the many detail records to be reassembled into a viewable format. There is a method of the service that basically just queries all the detail records for a particular session or XML Payload and concatenates the text into a single value. This method can be invoked from a calculated field and the calculated field exposed on a form applet. Because form applet fields are not the best way to see the data, I typically copy the data out of the field and into a text editor of choice. For instance I use Notepad++ with a Pretty Print add on to view XML payloads.
It will take several posts to go over the implementation in detail, but hopefully this whets people's appetites
Next: The XML Logger
No comments:
Post a Comment