Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve

Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve

Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve

Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve

Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve

Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve

Hi Riham,

I am puzzled by a "Network error" still being seen by your response rule.  I'd expect you to receive in the logs an "Unable to establish connection" error when a network error is encountered which typically bypasses the response rule and drives your error rule instead.   If your GatewayScript is on the response rule and is being executed, are you getting anything back in this readAsBuffer callback function?  I'd suggest you use the GatewayScript debugger.  You enable the debugger on your DataPower GatewayScript action and you will pause at the first debugger; statement executed in the code which I'd place as the first statement in your callback function.  You can follow how to use the debugger at https://www.ibm.com/docs/en/datapower-gateway/10.0.x?topic=debuggers-troubleshooting-process-gatewayscript.  It's a very useful tool that I'd personally be lost in debugging any GatewayScript program.  Otherwise, I think there is too much required to understand your issue on the community forum.  I'd suggest your open a PMR.  It would be best to include up front a DataPower probe export with one transaction that exhibits this behavior and would also have an export of your MPGW.  Also include an error report which would have the logs associated with the failing transaction.  Have the log level set to debug for this test.  I'd also provide a packet capture to the request rule's routing-url IP (specify in the packet capture config host <the ip of the backend> ) so it will only capture traffic between DataPower and your backend server.  If that url is a https (SSL) url, then on the packet capture, also specify to generate the ssl/tls session key file which you'll find after the packet capture in the logtemp: directory of your domain.  The actual packet capture will be in the temporary directory of your domain.  You should be able to see the request flowing to the backend and if any network issue, instead of a response there should be some packets that would help identify the problem.  Hopefully with this amount of documentation provided with the PMR DataPower support will be able to identify the issue.

Regards,

Steve

Hi Hisham,

First the response type of the MPGW must be non-XML.  If you wish to access this data in the DataPower response rule, you should edit the response rule from the Object menu in the navigation (Objects -> XML Processing -> Processing Rule) and enable non-XML processing.  Since the payload is binary I'd assume you would need to access it using a GatewayScript action that can consume non-XML payloads.  You should ensure that other non binary actions that may be in this rule don't access the INPUT context as it will cause a XML parse error.

Regards,
Steve