XML Logging

With Service Oriented systems it can be very important to have a log of the XML that has been sent and received by the systems involved, for purposes of determining exactly what went on to cause any given situation (usually an error situation, otherwise there would be no need to look into it). This article looks at how such things can be done. For how to then use the logged XML to investigate the problem see the related article XML Replay.

In general, once the raw XML has been obtained, one could log it in a number of ways, but for us the most natural would be to put it into a "Text" column in a database table.

Web Service Client XML Logging

Logging the XML sent by a web service client is relatively easy. It simply involves, following the service invocation, getting the psXML property of the object pointed to by the phoSoapRequest property of your web service client object. Something like this:

 
 tSomeInput Input
 tSomeOutput Output
 String  sXML
 Get wsSomeOp of oXyzService Input to Output
 Move (psXML(phoSoapRequest(oXyzService(Self)))) to sXML

Or, more verbosely:

 
 tSomeInput Input
 tSomeOutput Output
 String  sXML
 Handle  hoSoapReq
 Get wsSomeOp of oXyzService Input to Output
 Get phoSoapRequest of oXyzService to hoSoapReq
 Get psXML of hoSoapReq to sXML

Either way you now have the XML sent by your web service client and can log it in whatever way you require.

Web Service XML Logging

There is a very real difficulty regarding accessing the XML which is passed to a VDF Web Service (at least so far as revisions up to VDF 12.1 are concerned). The problem is that the original XML is nowhere available to the VDF program. One possible solution would be to employ some kind of HTTP proxy on the server involved, which would receive the XML (actually the HTTP within which the XML is wrapped) before it reached IIS, log that, then pass it on to IIS. However here we are going to concern ourselves only with the best that can be managed from within the VDF programming environment at the moment (November 2007).

The trick is to make use of a client of your service within the service itself. This in turn makes doing it a multi-stage process, since one can only create a client once the service is published and accessible.

Note: the code below is in brief and omits several important property settings which would normally be created on a web service.

Step 1: Define the Service

First you define your service (and get it running on IIS):

 
 Object oLogSample is a cWebService
   { Published = True  }
   { Description = "Interface for sending something to the system" }
   Procedure  SendSomething tSomeDocumentType Doc
      // Code that actually does stuff...
   End_Procedure  // SendSomething
 End_Object  // oLogSample

Step 2: Create a Client

Next you need to run the Web Service Client Class Generator (in the VDF Studio: File -> New -> Class -> Client Web Service Class) on the WSDL for your service (Test Page -> Service Name -> Service Description, then copy the browser's Address window to the Web Service Client Class Generator's WSDL URL window) and click "Parse", "Generate Class" and "OK" (plus "Yes" to overwrite if it already exists).

Step 3: Instantiate the client in the service

Now you need to use and instantiate the client class you have just generated within your service:

 Object oLogSample is a cWebService
   Use cWSLogSample.pkg
   Object oOwnService is a cWSLogSample
   End_Object // oOwnService
   { Published = True  }
   { Description = "Interface for sending something to the system" }
   Procedure  SendSomething tSomeDocumentType Doc
      // Code that actually does stuff...
   End_Procedure  // SendSomething
 End_Object  // oLogSample

Step 4: Use the client to transform the data back to XML

Finally you need to create a procedure that will utilise that client to reconstitute the XML from the data that your published method receives and call that procedure as the first thing each of your published methods do:

 Object oLogSample is a cWebService
   Use cWSLogSample.pkg
   Object oOwnService is a cWSLogSample
   End_Object  // oOwnService
   // LogMsg: The arguments are - 1 Data passed to the method
   //                             2 Name of the method (literal)
   //                             3 Name of the variable (literal)
   //                             4 Object handle for type - which will be named "oWS{typeName}"
   Procedure LogMsg Variant Data String sOp String sName Handle hoObj
      tSoapParameter Param
      Handle  hoXML hoDoc
      String  sXML
      Boolean bOK
      Get Create of Desktop U_cXmlDomDocument to hoXML
      Get CreateDocumentElementNS of hoXML (psServiceURI(Self)) sOp to hoDoc
      Get DefineStructParameter of oOwnService hoObj 1 1 sName (psServiceURI(Self)) to Param.SoapParamDef
      ValueTreeSerializeParameter Data to Param.ValueTree
      Get ValueTreeToXml of oOwnService Param.SoapParamDef Param.ValueTree hoDoc to bOK
      Get psXML of hoXml to sXML
      Send Destroy of hoDoc
      Send Destroy of hoXML
      // Now you can log sXML in some way...
   End_Procedure // LogMsg
   { Published = True  }
   { Description = "Interface for sending something to the system" }
   Procedure  SendSomething tSomeDocumentType Doc
      Send LogMsg Doc "SendSomething" "Doc" (oWStSomeDocumentType(oOwnService(Self)))
      // Code that actually does stuff...
   End_Procedure  // SendSomething
 End_Object  // oLogSample

Warning: Note that each time you change your service, you should regenerate the web service client (as in Step 2) immediately afterwards and then recompile your WebApp... again!

Issues

It is important to note that this mechanism does not retrieve the original XML, but instead reconstitutes it to the best of its ability from the data passed to the program. There are circumstances where such reconstituted XML might not match that actually sent to the service, especially if that was mal-formed in terms of the published WSDL service description. A specific example of this is when more than one element is passed when only one is expected: the program will receive (and hence log) only the first (expected) one and will be totally unaware of (and hence unable to log) any additional ones.