graphman New property handling

[Michael Mueller]

Dear Team.

recently we observed the following, when trying to deploy a service from a dev gateway to a target gateway.

DEV source gateway version 11.1.1

TEST target gateway version 11.0-CR2

Using the HTTP routing assertion in the source gateway results in xml code containing the assertion property:

<L7p:OmitAuthHeaderConnectReuseSystemDefault boxedBooleanValue="true"/>

When using the HTTP routing assertion in the target gateway, this property is not part of the code.

During prepartion of our deployment we compare old(target) and new(source) versions of xml code.
Hence we recognized this additional property.

Is there any concern to import this code from a newer gateway version to an older gateway version, using the graphman schema of the older version of course ?

Thank you

[Michael Mueller]

Hi Team.

meanwhile I figured out that this parameter is not gateway version related !!!

To reproduce:

• Insert a new http routing assertion into a policy code.
• Parameter is not included.
• Open routing assertion properties dialog, do not change anything , and confirm Dialog by Ok Button.
• Now the parameter is included.

That means, there is a new question:
If this assertion parameter is added to the assertions code representation, once you saved the assertions property dialog without changing anything. why isn't  the parameter included by default, when adding this assertion to the policy code only?

Anyway, as you can imagine, we are happy to see, that we don't have a deployment issue here.

Thank you

...Michael

[Joseph Fry]

Michael,

I will let the engineering team answer conclusively, but I can make some guesses.

This property was added in 10.1 CR2.  For backward compatibility they probably made the attribute optional in the policy XML.  As a result, it is also optional in graphql.  If it were a required attribute, then the upgrader would have had to touch that assertion in all policies, and there would have been no simple way of moving policy between versions.  I suspect there are other optional attributes across the assertions for similar reasons.

My guess is that they never modified the default boilerplate XML that gets added when the assertion is added to the policy... it would be unnecessary since that attribute is optional anyway.

[Michael Mueller]

Thank you very much Joseph.

Makes sense. 

Appreciated your response !!

Best regards

...MIchael

[Raju Gurram]

@Michael Mueller

Firstly, graphman schema has no influence over assertions unless you choose the non-xml format for the policy code and there's a bug with it.

Besides this, this field (OmitAuthHeaderConnectReuseSystemDefault) seemed to be boolean but it has third state i.e., null, which is used for the backward compatibility. 

This seemed buggy to me as well. Otherwise, please do note that, this field gets inserted when you click on [OK] button. I recommend you to go for [CANCEL] whenever you open any assertion dialog for read-purposes and wants to close it with no noise. 

Thanks.