Export with policyCodeFormat: "code" omits "Source Data" input parameter for "Generate Security Signature" Server module File

[ecelen-minvws]

Summary:

When exporting with the graphman client policyCodeFormat: "code", the generated bundle is missing the "Source Data" input parameter for the "Generate Security Signature" Server module files.

Steps to reproduce:

1. Create an assertion that contains a "Generate Security Signature" Server module file and configure all parameters.
2. Export with the following command: graphman export --gateway "default" --using folder --variables.folderPath "Graphman" --output "output.json" --options.policyCodeFormat code
3. Import with the following command: graphman import --gateway "default" --input "./output.json" --gateways.default.allowMutations

Expected Behavior

The exported bundle should include all configured input parameters for the "Generate Security Signature" Server module file, including "Source Data".

Actual Behavior

The "Source Data" input parameter is omitted from the exported bundle, even though it is configured in the policy.

"CustomAssertion": {
"name": "Generate Security Signature",
"valueClass": "com.l7tech.custom.assertions.generatesecuritysignature.GenerateSecuritySignatureAssertion",
"value": {
"algorithm": "SHA-256",
"lineBreak": "\r\n",
"privateKeyId": "0000000000000000000000000000000"
}

Issue:

Importing the policy from the exported bundle results in an incomplete configuration of the "Generate Security Signature" Server module because the Source Data parameter is missing.

• We are using graphman client v2.0.17 (schema v11.2.0)
• The bundle file itself is valid and can be processed.
• Observed when exporting with policyCodeFormat: "json", "code" or "yaml".
• No issues if we are exporting with policyCodeFormat: "xml", but we would like to store our bundle files in code format.

[graju256]

@ecelen-minvws You are correct; there is an issue with the assertion's bean definition.

Any field requiring JSON serialization must have matching getter and setter methods. In this case, the Source Data field has a getter method that does not follow the required serializer semantics.

FYI, the Source Data field in this Generate Security Signature custom assertion has the following set/get methods:

• setDataToSignText
• dataToSignText --> expected to be getDataToSignText

Gateway needs to be fixed for such instances. I will track this defect for the Gateway version 11.2 release.

Thanks.

[ecelen-minvws]

@graju256 Thank you for the confirmation.

I don't understand what should be fixed in the gateway for this issue. Is it not the Generate Security Signature custom assertion that should be fixed?

[graju256]

@ecelen-minvws Definitely we could think of fixing the assertion. But, what if another custom assertion brings the similar problem. Because of which, I'm just thinking of how to generalize the fix here.

[ecelen-minvws]

@graju256 Fair point