Error on Compare assertion

[Robert Kohler]

Using Gateway ver 9.4
No matter what I do to switch up the logic it always gives the same error on the compare, line 28.  Any ideas?

And goes in the log like this which is a 2,4,8,16,32 sec diff between them.

2020-03-31T21:22:10.138+0000 WARNING 250587 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -5: [FDX-39031658188389] Starting Policy: MONITOR-RCVPIX-HOLON

2020-03-31T21:22:33.149+0000 WARNING 250587 com.l7tech.server.event.AdminInfo: The administrative event caused as local call, outside of servicing an adminstrative remote call.Will use ip/user127.0.0.1/localsystem

2020-03-31T21:22:35.155+0000 WARNING 250583 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -5: [FDX-150117304217041] Starting Policy: MONITOR-RCVPIX-HOLON

2020-03-31T21:22:39.161+0000 WARNING 250584 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -5: [FDX-147964495146141] Starting Policy: MONITOR-RCVPIX-HOLON

2020-03-31T21:22:47.165+0000 WARNING 250585 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -5: [FDX-40062953976274] Starting Policy: MONITOR-RCVPIX-HOLON

2020-03-31T21:23:03.171+0000 WARNING 250586 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -5: [FDX-64930921149188] Starting Policy: MONITOR-RCVPIX-HOLON

2020-03-31T21:23:35.175+0000 WARNING 250587 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -5: [FDX-242325993772905] Starting Policy: MONITOR-RCVPIX-HOLON

------------------------------
Thanks for the help
Bob
------------------------------

[Irfan Mugale]

Hi Bob.

As per the screenshot it seems you are getting a empty result.
Please check if the rf9 value is passed in the xml packet. Currently it is empty due to which it is failing in compare assertion.

Thanks,

------------------------------
Application Development Analyst
Accenture
------------------------------

[Jay MacDonald]

Also, to be clear, if an XPath leads to an empty element then the value of ${xpath.found} will still be true, but the value of ${xpath.result} will be empty. For example:

Given message:
<foo>
  <bar>
    <baz />
  </bar>
</foo>

and XPATH: /foo/bar/baz

Then ${xpath.found}==true and ${xpath.result}=<empty>

Whereas:

Given message:
<foo>
  <bar>
    <baz>123</baz>
  </bar>
</foo>

and XPATH: /foo/bar/baz

Then ${xpath.found}==true and ${xpath.result}=123

Also, the XPath assertion will fail if the XPath is not found so checking for ${xpath.found}==true is actually moot in this logic

It would really help to capture the request message and confirm that the /tXML/Message/PIX/PIXFields/Reference9 element actually has a value.

By the way, I am curious as to why you are copying the request message to a new context variable rather than accessing the request message directly?

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Robert Kohler]

Correct the value in <Reference9></Reference9> could be blank.
So how to you get compare to deal with null values?

Bob

[Robert Kohler]

To clarify, 

The source will either have a value or be empty.
The requirement is to set a context variable if the path has a certain value.
So in keeping with your sample xml I need to set OT-aprf = "NEWCODE" if baz = "123"

The issue is that when I use compare to check for that value it fails when it's empty.

With respect to why separate variable I took this from another policy that was doing something similar, I'm not an expert so if you have better way I'm all ears.

[Robert Kohler]

Using the Evaluate Request XPath assertion didn't create any requestXpath variables. That is why the other developer used the Evaluate Resonse XPath assertion with the XML message source set to the context variable.

[Jay MacDonald]

Yeah, the compare assertion is a bit odd about how it handles null variables. I always assign a result from an XPath to a string context variable, that way if the result had been null then the context variable will be empty.

So, for starters, you don't need to copy the request message to run the XPath assertion. Unlike most of the assertions, which have a message targeting option, the Evaluate XPath functionality has two different assertions, one for requests and one for responses and arbitrary variables (the latter of which does have targeting, but it can't include the request). This is a holdover from the very early days of the Layer 7 policy language and one which I wish we would fix. Anyway, in your policy you are assigning the request payload to a new variable and using the Evaluate Response XPath assertion with that variable targeted. You should be using the Evaluate Request XPath assertion which automatically works on the request message so you don't need to spin cycles copying ${request.mainpart} to a new context variable.

I don't have any visibility into your policy beyond the screen shot and a description, but I suspect what you are trying to do is this:

I.e. the objective is to overwrite ${OT-aprf} with 'NEWVALUE' if /tXML/Message/PIX/PIXFields/Reference9 contains the string 'IB3'.If Reference9 is anything other than IB3 (including a blank element) then the value of ${OT-aprf} should be unchanged. If the XPath is not found at all then it should set INVALID STRUCTURE (is that trapping an error?).

Note that if you want the policy to check more possibilities then the logic in the At Least One folder (#8) will need to be inverted to look for equalities, not inequalities.

Let me know if this resolves your question.

Cheers!

JayMac

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Robert Kohler]

You are spot on with basic requirement.  I implemented it that way with one exception, the documentation says it should be requestXpath.result.
when ref9 has = "IB3" works fine, aprf is reset
when ref9 = "xxx" works fine, aprf unchanged
when ref9 = "" works fine, aprf unchanged
The trick was adding that folder around the compare instead if it being inline the way I had it.
thanks for the help Jay

[Jay MacDonald]

The prefix for the result can be set in the dialog, and by default is be requestXpath. I usually use a name that relates to what I am extracting, so in this case I would assign it to ref9, then set ${ref9} to ${ref9.result}. Note that in the policy language the "dot" notation is not strict at all, so assigning ${ref9.result} to ${ref9} will not overwrite any of the other dot values associated with the XPath (like ${ref9.found}.

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Francisc Cho]

noice sir that saves my time .. thanks for sharing