API Connect

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

I believe the [-1] is your issue.  I also used $queryParameter instead of $urlParameter.  The purpose of the $urlParameter is to simply provide the value for the named parameter which could be either a query or path parameter, so it should still work, but $queryParameter only looks at query parameters.  I'll attach my simple test case yaml where I have a query parameter named "echo" and the switch is $queryParameter('echo') = "true" and it works as I'd expect.  The echo query parameter not provided or not "true" takes me to the otherwise clause, but "true" passes the condition.  The other part of your condition "request.body.requestHeader.echoBack" is also incorrect if you're trying to check for a request header in addition to the query parameters.  Use "request.headers.echoBack = "true" in that case.  My sample checks for both now and is also working $queryParameter('echo') = 'true' or request.headers.echo = 'true'

Regards,
Steve

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

I believe the [-1] is your issue.  I also used $queryParameter instead of $urlParameter.  The purpose of the $urlParameter is to simply provide the value for the named parameter which could be either a query or path parameter, so it should still work, but $queryParameter only looks at query parameters.  I'll attach my simple test case yaml where I have a query parameter named "echo" and the switch is $queryParameter('echo') = "true" and it works as I'd expect.  The echo query parameter not provided or not "true" takes me to the otherwise clause, but "true" passes the condition.  The other part of your condition "request.body.requestHeader.echoBack" is also incorrect if you're trying to check for a request header in addition to the query parameters.  Use "request.headers.echoBack = "true" in that case.  My sample checks for both now and is also working $queryParameter('echo') = 'true' or request.headers.echo = 'true'

Regards,
Steve

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

I'm sorry, I didn't understand that the requestHeader was actually a json key in your JSON request payload.

First, request.body is immutable and cannot be parsed.  It will always be a string/binary data.  You should have a parse policy at the beginning of your API which will take the copy of request.body, which is always copied to message.body at the start of your assembly processing, and will parse it into a JSON object, replacing message.body.  Then stepping through that object with message.body.requestHeader.echo in the switch condition should work.

Regards,

Hi Santhoshkumar,

I believe the [-1] is your issue.  I also used $queryParameter instead of $urlParameter.  The purpose of the $urlParameter is to simply provide the value for the named parameter which could be either a query or path parameter, so it should still work, but $queryParameter only looks at query parameters.  I'll attach my simple test case yaml where I have a query parameter named "echo" and the switch is $queryParameter('echo') = "true" and it works as I'd expect.  The echo query parameter not provided or not "true" takes me to the otherwise clause, but "true" passes the condition.  The other part of your condition "request.body.requestHeader.echoBack" is also incorrect if you're trying to check for a request header in addition to the query parameters.  Use "request.headers.echoBack = "true" in that case.  My sample checks for both now and is also working $queryParameter('echo') = 'true' or request.headers.echo = 'true'

Regards,
Steve

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

I'm sorry, I didn't understand that the requestHeader was actually a json key in your JSON request payload.

First, request.body is immutable and cannot be parsed.  It will always be a string/binary data.  You should have a parse policy at the beginning of your API which will take the copy of request.body, which is always copied to message.body at the start of your assembly processing, and will parse it into a JSON object, replacing message.body.  Then stepping through that object with message.body.requestHeader.echo in the switch condition should work.

Regards,

Hi Santhoshkumar,

I believe the [-1] is your issue.  I also used $queryParameter instead of $urlParameter.  The purpose of the $urlParameter is to simply provide the value for the named parameter which could be either a query or path parameter, so it should still work, but $queryParameter only looks at query parameters.  I'll attach my simple test case yaml where I have a query parameter named "echo" and the switch is $queryParameter('echo') = "true" and it works as I'd expect.  The echo query parameter not provided or not "true" takes me to the otherwise clause, but "true" passes the condition.  The other part of your condition "request.body.requestHeader.echoBack" is also incorrect if you're trying to check for a request header in addition to the query parameters.  Use "request.headers.echoBack = "true" in that case.  My sample checks for both now and is also working $queryParameter('echo') = 'true' or request.headers.echo = 'true'

Regards,
Steve

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

Looking at your v5 screen shot, you have a condition in the switch apim.getvariable('request.parameters.echoBack') === 'true'  You are not doing anything with request.body in that example.  However, I've setup my own v5 API that has in the switch condition apim.getvariable('request.body.headers.echo') === 'true'  which works with my matching JSON payload in v5.

Since you used the AMU to do your migration, you should have a parse policy at the beginning of your assembly.  After some investigation, I see the AMU has code that will take request.body in some policy properties and changes it to request.parsed_body.   However, I don't believe this code is being applied against switch conditions.  I've tried request.parsed_body in my v10 test case of your scenario, ie, my condition is now $queryParameter('echo') = 'true' or request.parsed_body.headers.echo = 'true' and that works in both cases, but I don't believe the AMU is changing "body" to "parsed_body" in your switch conditionals.  Please open a PMR and provide your v5 source API that exhibits this condition.

Regards,

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

Original Message:
Sent: Tue February 22, 2022 11:36 AM
From: santhoshkumar surisetty
Subject: how to refer payloads in switch policy

you mean to say that we can't refer request.body anywhere in v10 , if we want refer any elements in the intial request message , we need to save it in the context variable  after parse it and refer it in switch condition. before calling backend. unfortunately we have so many conditons in v5 like this . we endup the recoding wherever we have this condition


   request message -> parsepolicy( message.body) -> need to write gateway script to save this message in context variable and transform message to xml -invoke -> switch ( context variable where we saved request message)

------------------------------
santhoshkumar surisetty

Original Message:
Sent: Tue February 22, 2022 11:08 AM
From: Steve Linn
Subject: how to refer payloads in switch policy

Hi Santhoshkumar,

I'm sorry, I didn't understand that the requestHeader was actually a json key in your JSON request payload.

First, request.body is immutable and cannot be parsed.  It will always be a string/binary data.  You should have a parse policy at the beginning of your API which will take the copy of request.body, which is always copied to message.body at the start of your assembly processing, and will parse it into a JSON object, replacing message.body.  Then stepping through that object with message.body.requestHeader.echo in the switch condition should work.

Regards,

Hi Santhoshkumar,

I believe the [-1] is your issue.  I also used $queryParameter instead of $urlParameter.  The purpose of the $urlParameter is to simply provide the value for the named parameter which could be either a query or path parameter, so it should still work, but $queryParameter only looks at query parameters.  I'll attach my simple test case yaml where I have a query parameter named "echo" and the switch is $queryParameter('echo') = "true" and it works as I'd expect.  The echo query parameter not provided or not "true" takes me to the otherwise clause, but "true" passes the condition.  The other part of your condition "request.body.requestHeader.echoBack" is also incorrect if you're trying to check for a request header in addition to the query parameters.  Use "request.headers.echoBack = "true" in that case.  My sample checks for both now and is also working $queryParameter('echo') = 'true' or request.headers.echo = 'true'

Regards,
Steve

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,

Hi Santhoshkumar,

Looking at your v5 screen shot, you have a condition in the switch apim.getvariable('request.parameters.echoBack') === 'true'  You are not doing anything with request.body in that example.  However, I've setup my own v5 API that has in the switch condition apim.getvariable('request.body.headers.echo') === 'true'  which works with my matching JSON payload in v5.

Since you used the AMU to do your migration, you should have a parse policy at the beginning of your assembly.  After some investigation, I see the AMU has code that will take request.body in some policy properties and changes it to request.parsed_body.   However, I don't believe this code is being applied against switch conditions.  I've tried request.parsed_body in my v10 test case of your scenario, ie, my condition is now $queryParameter('echo') = 'true' or request.parsed_body.headers.echo = 'true' and that works in both cases, but I don't believe the AMU is changing "body" to "parsed_body" in your switch conditionals.  Please open a PMR and provide your v5 source API that exhibits this condition.

Regards,

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

Original Message:
Sent: Tue February 22, 2022 11:36 AM
From: santhoshkumar surisetty
Subject: how to refer payloads in switch policy

you mean to say that we can't refer request.body anywhere in v10 , if we want refer any elements in the intial request message , we need to save it in the context variable  after parse it and refer it in switch condition. before calling backend. unfortunately we have so many conditons in v5 like this . we endup the recoding wherever we have this condition


   request message -> parsepolicy( message.body) -> need to write gateway script to save this message in context variable and transform message to xml -invoke -> switch ( context variable where we saved request message)

------------------------------
santhoshkumar surisetty

Original Message:
Sent: Tue February 22, 2022 11:08 AM
From: Steve Linn
Subject: how to refer payloads in switch policy

Hi Santhoshkumar,

I'm sorry, I didn't understand that the requestHeader was actually a json key in your JSON request payload.

First, request.body is immutable and cannot be parsed.  It will always be a string/binary data.  You should have a parse policy at the beginning of your API which will take the copy of request.body, which is always copied to message.body at the start of your assembly processing, and will parse it into a JSON object, replacing message.body.  Then stepping through that object with message.body.requestHeader.echo in the switch condition should work.

Regards,

Hi Santhoshkumar,

I believe the [-1] is your issue.  I also used $queryParameter instead of $urlParameter.  The purpose of the $urlParameter is to simply provide the value for the named parameter which could be either a query or path parameter, so it should still work, but $queryParameter only looks at query parameters.  I'll attach my simple test case yaml where I have a query parameter named "echo" and the switch is $queryParameter('echo') = "true" and it works as I'd expect.  The echo query parameter not provided or not "true" takes me to the otherwise clause, but "true" passes the condition.  The other part of your condition "request.body.requestHeader.echoBack" is also incorrect if you're trying to check for a request header in addition to the query parameters.  Use "request.headers.echoBack = "true" in that case.  My sample checks for both now and is also working $queryParameter('echo') = 'true' or request.headers.echo = 'true'

Regards,
Steve

storageType is added by us to verify what it returns as the request.body.requestHeader.echoback refrecnce is not working . we are still looking for the solution. 

v5 condition
=======


v10 condition
============

Thanks Santhoshkumar,

I would be curious if you would post just the if/switch condition in your v5 switch that is being migrated to $storageType.  I could try a quick recreate in the AMU while waiting for the PMR.

Regards,

 Hi Santhoshkumar,

$storageType per the API Connect documentation for jsonata functions of a switch should return one of   "binary" | "json" | "stream" | "xml".  See https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=switch-writing-condition-scripts-datapower-api-gateway.   I  don't see $storageType in the current AMU code base, but that's not to say it wasn't there in AMU tool 10.0.3 -r2 version and been removed with recent revisions.  What was your v5 switch condition that produced this resulting switch condition in the v10 api?  Investigation of this would be best if you were to open a PMR for this.  Please provide your v5 API yaml file and the resulting v10 API Gateway API yaml file with the issue and any AMU logs if you still have them.  As for your question "do we need to rewrite it for all APIs , if we have similar conditions." the AMU is a migration tool meant to be a one time usage tool.  Your options would be to fix any failing API or assuming this is a defect in the AMU, rerun the v5 to v10 migration when a fix is available.  I understand that isn't the most desired answer, hopefully what produced this is isolated to a particular type of v5 condition that doesn't impact a large number of APIs.

Regards,

Hi Santhoshkumar,

When you say "element in the request message" is your input XML or JSON?  "Element" to me says XML.  You'll first need to start off your assembly with a parse policy.  That will take the raw text in the request message and will parse it into either an XML DOM or JSON object depending upon what your payload is.  The parse of the request will be stored in the context "message" so then your switch condition would be

message.body.parent.child.element = '1'

That should work for JSON and for XML if your XML has no namespaces.  If your XML does have a namespace or if you need to test against an XML attribute, then you'll need to use the $xpath function, for example

$xpath(message.body, '/*[@local-name() = 'parent']/*[@local-name() = 'child']/*[@local-name() = 'element'']) = 1

Regards,