DataPower

 View Only

  • 1.  Any way to access raw input after an XML Parse error?

    Posted Mon May 22, 2023 09:54 AM

    We've got a MPGW that expects XML input, and the consumer of this service sometimes sends us invalid XML (in particular, non-UTF8 characters).

    We catch the 0x00030001 error in our error rule and log the error.  We've now been asked to log the incoming payload that causes the error.

    Is there any way for us to actually see the raw input in the error rule's XSL?  I've already tried looking at dp:variable('var://context/INPUT') but that seems to be empty by the time the error rule has kicked in.



    ------------------------------
    Jim Russell
    ------------------------------


  • 2.  RE: Any way to access raw input after an XML Parse error?

    IBM Champion
    Posted Mon May 22, 2023 10:30 AM

    Jim, 

    A quick way is to push the input context of the request into a context variable right after receiving it.
    You then have access to it anytime you need it.



    ------------------------------
    Joseph Morgan
    ------------------------------

    Original Message


  • 3.  RE: Any way to access raw input after an XML Parse error?

    IBM Champion
    Posted Mon May 22, 2023 11:00 AM
    Edited by Joseph Morgan Mon May 22, 2023 11:01 AM

    Jim, 

    It just occurred to me, too, you'll have to set the rule and the action to process non-XML, otherwise it may not even make it into your policy is any meaningful way.



    ------------------------------
    Joseph Morgan
    ------------------------------

    Original Message


  • 4.  RE: Any way to access raw input after an XML Parse error?

    Posted Mon May 22, 2023 03:30 PM

    Hi Jim,

    Just to confirm, your MPGW has a request type of XML, so the parse error you're getting is the implicit parse that happens before your actual request rule processing begins?

    It's been a while since I've done this with a MPGW that wasn't webapi from API Connect :-) I think the INPUT context in the request rule will be made available to the error rule, but you'll need to verify that.  What does the DataPower probe show you as the INPUT context to your error rule?  Of course, if this is the case but the implicit parse failed, you can't have a xsl that uses INPUT as the input context as it would fail with the same parse error.  However, in your error rule xsl you can do something like the following:

    <xsl:variable name="input" select="dp:variable('var://context/INPUT')" /> <!-- This will produce a binary node since the parse hasn't happened -->
<xsl:variable name="rawinput">
  <xsl:if test="dp:isBinaryNode($input)">
    <xsl:value-of select="dp:binaryNodeToString($input)" />
  </xsl:if>
</xsl:variable>

    If the binary node is not available to you in the error rule, then as Joseph points out, you may have to set the service request-type be non-XML, use the options menu to access the request rule and enable non-xml processing, and do the parse yourself in your request rule.  You'd still need to above code to access the data, and again all of this is assuming that the INPUT context in your error rule would be the same as your request rule.  You may also need to set the non-XML option on your error rule too.  I'd be curious what your final solution is.

    Best Regards,

    Steve



    ------------------------------
    Steve Linn
    Senior Consulting I/T Specialist
    IBM
    ------------------------------

    Original Message


  • 5.  RE: Any way to access raw input after an XML Parse error?

    IBM Champion
    Posted Tue May 23, 2023 06:58 AM

    Hi Jim,

    Joseph and Steve already gave good suggestions how to solve the issue. When you get past the parsing error are you trying to log the invalid message to DataPower log or to some other place? We have had similar cases with some of our consumers and because DataPower log isn't very useful in storing large messages we have either written the invalid messages to local temporary folder or sent them to some external log management tool using for example url-open. Hope this helps.



    ------------------------------
    Hermanni Pernaa
    ------------------------------

    Original Message