Hello Everyone,

Hello All,

Could anyone help me on this with your thoughts?

Hello Everyone,

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

Thank you for your response.

Case 2: We come to know that  there are some issues with api-probe settings and we have to fix it to see the trace.  Then we will log the message and  see what's actually coming.

Coming to storing the token, Our DataPower is on 10.5.0.11 and APIC is on 10.0.5.7. Since you confirmed distributed values comes up with DataPower 10.6, Is there any way to achieve this in with APIC 10.0.5.7 and DP 10.5.0.11?

------------------------------
Kumar

Original Message:
Sent: Wed August 07, 2024 09:46 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hello @Steve Linn,

Clearing the content-type after first invoke, Now we were able to receive the expected response. 

Coming to storing the token, As per the below information we can configure the Invoke with Time to Live and specifying the value of token expiry time. Can we consider this option?

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=invoke-configuring-policy-datapower-api-gateway

Dear Steve,

Thank you for your response.

Case 2: We come to know that  there are some issues with api-probe settings and we have to fix it to see the trace.  Then we will log the message and  see what's actually coming.

Coming to storing the token, Our DataPower is on 10.5.0.11 and APIC is on 10.0.5.7. Since you confirmed distributed values comes up with DataPower 10.6, Is there any way to achieve this in with APIC 10.0.5.7 and DP 10.5.0.11?

------------------------------
Kumar

Original Message:
Sent: Wed August 07, 2024 09:46 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,

The invoke policy caching options will only work if your request does not have an Authorization header.  Given it is returning a security token of some type I had made the assumption that you do have an Authorization header being sent to your backend, which is why I suggested the side call service, so yes, you could use this option on the invoke policy but you'd need two separate services, for example

1. API 1 invoke sends a request to API2 with the invoke TTL specified.  Any request headers are send to API2 using your own named headers, NOT Authorization.
2. API2 takes those named headers, builds the Authorization header, and contacts your real backend, gets the response and returns it to API1.

Now API1's communication to API2 will be cached.  API2 will always communicate to your authentication server, but it will be called less frequently because of API1's invoke cache policy.

Best Regards,
Steve

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

Original Message:
Sent: Wed August 14, 2024 04:58 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hello @Steve Linn,

Clearing the content-type after first invoke, Now we were able to receive the expected response. 

Coming to storing the token, As per the below information we can configure the Invoke with Time to Live and specifying the value of token expiry time. Can we consider this option?

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=invoke-configuring-policy-datapower-api-gateway

------------------------------
Kumar

Original Message:
Sent: Thu August 08, 2024 03:13 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

Thank you for your response.

Case 2: We come to know that  there are some issues with api-probe settings and we have to fix it to see the trace.  Then we will log the message and  see what's actually coming.

Coming to storing the token, Our DataPower is on 10.5.0.11 and APIC is on 10.0.5.7. Since you confirmed distributed values comes up with DataPower 10.6, Is there any way to achieve this in with APIC 10.0.5.7 and DP 10.5.0.11?

------------------------------
Kumar

Original Message:
Sent: Wed August 07, 2024 09:46 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

May I know about the API1 and API2 endpoints, I assumed that they are on different internet address endpoints and that the re-negotiation message happened during the high-priority service request for the active job. 

How long does the cache policy expire date time? After the maintenance services application can perform the same process negotiation with the same scenarios? Can we know when the cache policy is active? How do we identify the cache policy involved in communication from regular messages?

It is a good service and I would like to study more about the API gateway more...

Thank you

- - -

------------------------------
Jirayu Kaewprateep

Original Message:
Sent: Wed August 14, 2024 09:13 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,

The invoke policy caching options will only work if your request does not have an Authorization header.  Given it is returning a security token of some type I had made the assumption that you do have an Authorization header being sent to your backend, which is why I suggested the side call service, so yes, you could use this option on the invoke policy but you'd need two separate services, for example

1. API 1 invoke sends a request to API2 with the invoke TTL specified.  Any request headers are send to API2 using your own named headers, NOT Authorization.
2. API2 takes those named headers, builds the Authorization header, and contacts your real backend, gets the response and returns it to API1.

Now API1's communication to API2 will be cached.  API2 will always communicate to your authentication server, but it will be called less frequently because of API1's invoke cache policy.

Best Regards,
Steve

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

Original Message:
Sent: Wed August 14, 2024 04:58 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hello @Steve Linn,

Clearing the content-type after first invoke, Now we were able to receive the expected response. 

Coming to storing the token, As per the below information we can configure the Invoke with Time to Live and specifying the value of token expiry time. Can we consider this option?

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=invoke-configuring-policy-datapower-api-gateway

------------------------------
Kumar

Original Message:
Sent: Thu August 08, 2024 03:13 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

Thank you for your response.

Case 2: We come to know that  there are some issues with api-probe settings and we have to fix it to see the trace.  Then we will log the message and  see what's actually coming.

Coming to storing the token, Our DataPower is on 10.5.0.11 and APIC is on 10.0.5.7. Since you confirmed distributed values comes up with DataPower 10.6, Is there any way to achieve this in with APIC 10.0.5.7 and DP 10.5.0.11?

------------------------------
Kumar

Original Message:
Sent: Wed August 07, 2024 09:46 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Jirayu,
Your current API is API1.  It is doing an invoke to some server that is returning an authentication token, and you are asking how to "cache" that token so you don't go to that server for every request.  I'm suggesting that instead of API1 using that authentication server as it's back, that you would use another service as your backend.  It could be a MPGW server, or it could be another API endpoint, which is what I was calling API2. This other service/API would interact with the authentication server and would return the token in its response.

API1 has caching properties in its configuration, so you're in control.  If you choose a cache type of "Time to Live" then you provide a fixed time.  You could also choose a "Protocol" type which would then require that your MPGW/API2 return the Cache-Control response header that would control the cache duration.  Other headers may also apply, but see https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=manager-defining-document-cache-policies for the rules.

Specific answers to your questions:

> How long does the cache policy expire date time?
As I indicated, fixed with TTL, or by Cache-Control response and other headers if protocol type.

> After the maintenance services application can perform the same process negotiation with the same scenarios?
I'm not sure of your question here, please elaborate.

> Can we know when the cache policy is active?
There is a DataPower status provider that will show the currently active documents in the cache

> How do we identify the cache policy involved in communication from regular messages?
If you're asking if you'll know if the document read was from the backend or from the cache, generally you will not know.  You do an invoke to a http(s) backend and you get a response back.  Whether it came from the cache or was the actual backend call that was cached isn't known.

Hope this helps,
Best Regards,
Steve Linn

Dear Steve,

May I know about the API1 and API2 endpoints, I assumed that they are on different internet address endpoints and that the re-negotiation message happened during the high-priority service request for the active job. 

How long does the cache policy expire date time? After the maintenance services application can perform the same process negotiation with the same scenarios? Can we know when the cache policy is active? How do we identify the cache policy involved in communication from regular messages?

It is a good service and I would like to study more about the API gateway more...

Thank you

- - -

------------------------------
Jirayu Kaewprateep

Original Message:
Sent: Wed August 14, 2024 09:13 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,

The invoke policy caching options will only work if your request does not have an Authorization header.  Given it is returning a security token of some type I had made the assumption that you do have an Authorization header being sent to your backend, which is why I suggested the side call service, so yes, you could use this option on the invoke policy but you'd need two separate services, for example

1. API 1 invoke sends a request to API2 with the invoke TTL specified.  Any request headers are send to API2 using your own named headers, NOT Authorization.
2. API2 takes those named headers, builds the Authorization header, and contacts your real backend, gets the response and returns it to API1.

Now API1's communication to API2 will be cached.  API2 will always communicate to your authentication server, but it will be called less frequently because of API1's invoke cache policy.

Best Regards,
Steve

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

Original Message:
Sent: Wed August 14, 2024 04:58 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hello @Steve Linn,

Clearing the content-type after first invoke, Now we were able to receive the expected response. 

Coming to storing the token, As per the below information we can configure the Invoke with Time to Live and specifying the value of token expiry time. Can we consider this option?

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=invoke-configuring-policy-datapower-api-gateway

------------------------------
Kumar

Original Message:
Sent: Thu August 08, 2024 03:13 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

Thank you for your response.

Case 2: We come to know that  there are some issues with api-probe settings and we have to fix it to see the trace.  Then we will log the message and  see what's actually coming.

Coming to storing the token, Our DataPower is on 10.5.0.11 and APIC is on 10.0.5.7. Since you confirmed distributed values comes up with DataPower 10.6, Is there any way to achieve this in with APIC 10.0.5.7 and DP 10.5.0.11?

------------------------------
Kumar

Original Message:
Sent: Wed August 07, 2024 09:46 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

Thank you for your answer, I question these because I have experience with the API-implemented architecture with different endpoints of API1 and API2.

[Jirayu]: After the maintenance services application can perform the same process negotiation with the same scenarios?
[Steve]: I'm not sure of your question here, please elaborate.

[Jirayu]: After restarting our system for maintenance application previously working with API endpoint version 1 will try to connect to API endpoint version 2 because both are identified in the configuration and it creates concurrent sessions. Are there any limited of the number of concurrent sessions or a number of error retires?  

[Jirayu]: Can we know when the cache policy is active?
[Steve]: There is a DataPower status provider that will show the currently active documents in the cache

[Jirayu]: That is a good tools monitoring status.

[Jirayu]:  How do we identify the cache policy involved in communication from regular messages?
[Steve]: If you're asking if you'll know if the document read was from the backend or from the cache, generally you will not know.  You do an invoke to a http(s) backend and you get a response back.  Whether it came from the cache or was the actual backend call that was cached isn't known.

[Jirayu]: That is exactly my question do you have any option for update document or start query for new request for same resultset?

Thank you

- - -

I am studying and learning from online courses and this is my hobbies

Hi Jirayu,
Your current API is API1.  It is doing an invoke to some server that is returning an authentication token, and you are asking how to "cache" that token so you don't go to that server for every request.  I'm suggesting that instead of API1 using that authentication server as it's back, that you would use another service as your backend.  It could be a MPGW server, or it could be another API endpoint, which is what I was calling API2. This other service/API would interact with the authentication server and would return the token in its response.

API1 has caching properties in its configuration, so you're in control.  If you choose a cache type of "Time to Live" then you provide a fixed time.  You could also choose a "Protocol" type which would then require that your MPGW/API2 return the Cache-Control response header that would control the cache duration.  Other headers may also apply, but see https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=manager-defining-document-cache-policies for the rules.

Specific answers to your questions:

> How long does the cache policy expire date time?
As I indicated, fixed with TTL, or by Cache-Control response and other headers if protocol type.

> After the maintenance services application can perform the same process negotiation with the same scenarios?
I'm not sure of your question here, please elaborate.

> Can we know when the cache policy is active?
There is a DataPower status provider that will show the currently active documents in the cache

> How do we identify the cache policy involved in communication from regular messages?
If you're asking if you'll know if the document read was from the backend or from the cache, generally you will not know.  You do an invoke to a http(s) backend and you get a response back.  Whether it came from the cache or was the actual backend call that was cached isn't known.

Hope this helps,
Best Regards,
Steve Linn

Dear Steve,

May I know about the API1 and API2 endpoints, I assumed that they are on different internet address endpoints and that the re-negotiation message happened during the high-priority service request for the active job. 

How long does the cache policy expire date time? After the maintenance services application can perform the same process negotiation with the same scenarios? Can we know when the cache policy is active? How do we identify the cache policy involved in communication from regular messages?

It is a good service and I would like to study more about the API gateway more...

Thank you

- - -

------------------------------
Jirayu Kaewprateep

Original Message:
Sent: Wed August 14, 2024 09:13 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,

The invoke policy caching options will only work if your request does not have an Authorization header.  Given it is returning a security token of some type I had made the assumption that you do have an Authorization header being sent to your backend, which is why I suggested the side call service, so yes, you could use this option on the invoke policy but you'd need two separate services, for example

1. API 1 invoke sends a request to API2 with the invoke TTL specified.  Any request headers are send to API2 using your own named headers, NOT Authorization.
2. API2 takes those named headers, builds the Authorization header, and contacts your real backend, gets the response and returns it to API1.

Now API1's communication to API2 will be cached.  API2 will always communicate to your authentication server, but it will be called less frequently because of API1's invoke cache policy.

Best Regards,
Steve

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

Original Message:
Sent: Wed August 14, 2024 04:58 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hello @Steve Linn,

Clearing the content-type after first invoke, Now we were able to receive the expected response. 

Coming to storing the token, As per the below information we can configure the Invoke with Time to Live and specifying the value of token expiry time. Can we consider this option?

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=invoke-configuring-policy-datapower-api-gateway

------------------------------
Kumar

Original Message:
Sent: Thu August 08, 2024 03:13 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Dear Steve,

Thank you for your response.

Case 2: We come to know that  there are some issues with api-probe settings and we have to fix it to see the trace.  Then we will log the message and  see what's actually coming.

Coming to storing the token, Our DataPower is on 10.5.0.11 and APIC is on 10.0.5.7. Since you confirmed distributed values comes up with DataPower 10.6, Is there any way to achieve this in with APIC 10.0.5.7 and DP 10.5.0.11?

------------------------------
Kumar

Original Message:
Sent: Wed August 07, 2024 09:46 AM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar, 
For case 2, it seems that your backend is failing on the validation of the payload it is being sent.  You may have the same bearer token in both cases, but what is in message.body in both cases?  That is assuming of course that for the invoke policies of your two API2 APIs, that each invoke is doing a POST method.  The contents of message.body will be the request payload sent to your backend.  Perhaps you could have a GatewayScript prior to each invoke that would get message.body and simply log it for examination if you have difficulty doing the packet capture.

As for how to store your token, I would suggest the use of a relatively new DataPower feature called distributed variables.  These variables are shared between multiple appliances all within the same peer group, thus the same token can be utilized on each appliance although it would have been obtained on the one appliance of the group that communicated with the token backend server.  You can read about distributed variables at https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=administration-distributed-variables Note that the distributed variable feature was introduced in DataPower firmware 10.6.  I would suggest in your case using a xslt stylesheet, at least for saving your token, as the dp:set-dist-variable extension element (See https://www.ibm.com/docs/en/datapower-gateway/10.6?topic=elements-dpset-dist-variable) supports a time to live attribute (expire) that the equivalent GatewayScript capability doesn't support at theis time.  Since your token expires in 7199 seconds, you could set the distributed variable expire to something less, say 7170 seconds.  When you attempt on a subsequent transaction to get this distributed variable, if it is expired you'll not get a result which would tell you to hit your backend to get a new token and save a new token in the distributed cache for another 7170 seconds.

Best Regards,
Steve Linn

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

Original Message:
Sent: Wed August 07, 2024 08:08 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Steve,

Thanks for your Inputs. I have tried through test tab and nothing is coming in the trace except the same error message.Now, we are only left with packet capturing and we will do.

Meanwhile, Let me explain what we have been trying to achieve.

Case 1)Test_API1 --> Invoke(Token API which is another API service hosted on same APIC Manager)  --> Gateway script(get access-token from json response and set apikey as http header)-->Invoke( Actual backend). 
This scenario is working fine without any issues.

 Case 2)Test_API2-->Invoke(Token API which is another API service hosted on same APIC Manager)--> Gateway script(set Authorization Bearer as http header)-->Invoke( Actual backend)-->Parse

 This scenario is giving error. I though it would fail at response parse but it didn't fail. So, whatever the error response we are receiving that is clearly coming from the backend as per datapower and apic analytics logs.

So, we have  created another Test_API2 with another version(2.0.0) there I only configured the Invoke with same backend that I have configured in Case2 Second Invoke. I hit the api endpoint by passing Authorization: Bearer Token manually then backend has given valid response.

So, I am not getting what exactly am missing when we call Case2? 

------------------------------
Kumar

Original Message:
Sent: Tue August 06, 2024 05:56 PM
From: Steve Linn
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly

Hi Kumar,
 Just looking at the error message, it would appear that some process is expecting a JSON payload and somewhere in its validation of that payload there is a validation error.  I'm not aware of a JSONThreatProtection policy within APIConnect, but a quick internet search showed that there is a competitive product that has a policy by that name. It is hard to diagnose your issue with just the information you've provided, but my best guess with the limited information is that API2 must be doing an invoke to some backend and passing a payload that is failing validation.  If you can execute API2 directly from the API Manager test tab, you can get a trace on the test tab and be able to look at the context for message.body for the invoke policy action to see exactly what is being sent.  Either it is malformed JSON or perhaps isn't JSON at all.  Unfortunately, the faultstring doesn't even provide an offset to know where the issue is.  If you can't use the test tab for API2, what type of platform are you using?  If you by chance have a virtual or physical DataPower, a packet capture to your API2 backend requesting tls session keys so the traffic can be decrypted would be very useful to see what was sent to the backend and hopefully you'd see the above response.
Best Regards,
Steve Linn

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

Original Message:
Sent: Mon August 05, 2024 03:15 AM
From: Kumar .
Subject: Getting "steps.jsonthreatprotection.ExecutionFailed" when we call another api(Invoke) inside the assembly