XML Replay: Difference between revisions

From DataFlex Wiki
Jump to navigationJump to search

XML Replay (view source)

Revision as of 16:56, 6 November 2007

877 bytes removed ,  6 November 2007
Removed section about fixing up logged XML, as the problem has been resolved there
mNo edit summary
(Removed section about fixing up logged XML, as the problem has been resolved there)
Line 1: Line 1:
When attempting to diagnose problems which occur within web service environments, it is often useful to be able to re-run the XML which triggered the problem, so as to be able to step through it in the Visual DataFlex Studio debugger.  The XML passed to a web service can be logged (see [[XML logging]] for details of how this can be done) and this historic data can then be used to "''replay''" the offending call and see what probably happened.
When attempting to diagnose problems which occur within web service environments, it is often useful to be able to re-run the XML which triggered the problem, so as to be able to step through it in the Visual DataFlex Studio debugger.  The XML passed to a web service can be logged (see [[XML logging]] for details of how this can be done) and this historic data can then be used to "''replay''" the offending call and see what probably happened.


Assuming you have access to the original XML (see [[XML logging]]), this can then be saved into a text file - usually with the extension ".xml".  If this has been logged using the mechanism suggested in the XML logging article, it may need to be slightly doctored before being sent for replay.  This is because, for obscure reasons, the message namespace gets attached to the first child element of the message XML, instead of to the parent itself, thus:
Assuming you have access to the original XML (see [[XML logging]]), this can then be saved into a text file - usually with the extension ".xml".  This XML is then ready for incorporation into a SOAP message for re-sending to your service, running under a debugger, so you can set breakpoints and trace the execution through, step by step.
 
<MessageName>
  <ParameterName <font color="red">xmlns="<nowiki>http://myDomain/myURI</nowiki>"</font>>
    <Element1>Foo</Element1>
    <Element2>Bar</Element2>
    <Element3>Etc.</Element3>
  </ParameterName>
</MessageName>
 
Instead of the correct:
 
<MessageName <font color="blue">xmlns="<nowiki>http://myDomain/myURI</nowiki>"</font>>
  <ParameterName>
    <Element1>Foo</Element1>
    <Element2>Bar</Element2>
    <Element3>Etc.</Element3>
  </ParameterName>
</MessageName>
 
Once this has been corrected (either manually or in your replay program), the XML is then ready for incorporation into a SOAP message for re-sending to your service, running under a debugger so you can set breakpoints and trace the execution through, step by step.


In order to do this however, you are going to need a client which operates at a lower level than the standard web service client class you are able to generate for your service using the Studio's Web Service Client Class Generator.  The following is an example of how you might do this using an object of the cXmlHttpTransfer class.
In order to do this however, you are going to need a client which operates at a lower level than the standard web service client class you are able to generate for your service using the Studio's Web Service Client Class Generator.  The following is an example of how you might do this using an object of the cXmlHttpTransfer class.
Retrieved from "https://dataflex.wiki/index.php?title=Special:MobileDiff/819"

Navigation menu