XML Logging: Difference between revisions

m
Minor fixes
m (XML logging moved to XML Logging: Uppercase the "L")
m (Minor fixes)
Line 1: Line 1:
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]].
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==
==Web Service Client XML Logging==
Line 24: Line 25:


==Web Service XML Logging==
==Web Service XML Logging==
There is a very real difficulty regarding accessing the XML which is passed it 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).
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.
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.