Hello Team,

I’m trying to use Invoke webMethods IS in the API GW. The idea is to reject customer request with appropriate http code and message when the business logic is misapplied.

Until now i’m doing this by throwing exception inside the IS service to stop request but the customer get http code ‘500 Internal Server Error’.

Is there a better way to reject the request ? and how i can adapt the returning code/response ?

Thank you in advance.

BR

Hi Ahmed,

You can set the “service.exception.status.code” and “service.exception.status.message” in the message context to achieve this. I am pasting the screenshot from the document below. Hope this helps.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/dc00efa1f5077f2e5177221dc654712dfc8e84ec_2_1035x472.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/dc00efa1f5077f2e5177221dc654712dfc8e84ec_2_1380x630.png 2x" data-dominant-color="EEEEED">

image1527×698 74.2 KB

Regards,
Vallab

Hello Vallab,

Thank you for your reply.

I tried this before but i’m not able to find the right class to use

I tried all suggested class but doesn’t resolve the error

Thanks

Hi Ahmed,

For writing IS service programmatically (usage of MessagContext) etc, you can refer this article and the IS package attached here. Invoke webMethods IS policy in API Gateway 10.1 and below

In your case, the MessageContext you need to import is “org.apache.synapse.MessageContext”.

Add the below jars in the build path for the package in Software AG Designer.

• axis2-kernel-.jar, axis2-transport-http-.jar and synapse-core-*.jar from <Install_Location>\WS-Stack\lib
• <Install_Location>\IntegrationServer\instances\default\packages\WmAPIGateway\code\jars\apigateway-runtime.jar
• <Install_Location>\IntegrationServer\instances\default\packages\WmAPIGateway\code\jars\static\apigateway-API.jar

The above changes are to resolve the compile time errors thrown by Designer during edit and save of the java services inside the package. Also, make sure wmAPIGateway package is added as the package dependency to this package (this is for runtime).

For screenshot references of above steps, refer the tech forums link I shared above.

Regards,
Vallab

Dropping to Java to set return codes – ugh.

The service specification (for request and response processing) lists statusCode and statusMessage as output. Presumably setting those will achieve the same? Seems may be no need to write Java (small snippet, though it is) and futz with the build path. Just set the outputs. Presumably that will do what is desired (otherwise, what is the point of the the output parameters?)

@raemon The statusCode and statusMessage which are part of output are for accessing/modifying the statusCode and statusMessage of the native server responses before sending to client. (This option is available only in Response Processing and even for Response Processing, the user scenario is different. Read more below)

In this case, the user is asking about how to modify status code when exception is thrown intentionally from IS Service. You can read the doc snapshot in my first comment to understand more about this usecase.

Regards,
Vallab

I may indeed have misunderstood what the OP is asking about. Here are the places where an IS service is in play:

• Request Processing – called to manipulate things before calling the native service. Can change a variety of items. Can conform to pub.apigateway.invokeISService.specifications that has statusCode and statusMessage outputs.

• Routing - Call an IS service as the “native service”. In this case, API GW doesn’t know and doesn’t care that the service is on IS. It just makes an http call. If this service needs to fail with specific codes/messages then modify the IS service to do so. If the service cannot be modified (or you don’t want to), then Response Processing might be used to help translate.

• Response Processing - called to manipulate things after calling the native service. Can change a variety of items including response code/message. Can conform to pub.apigateway.invokeISService.specifications that has statusCode and statusMessage outputs. If it is to translate native response to something else, then you’ll need enough data in the request or response to do so.

Given the original post, it may be that we wandered off into things to be done in the GW but missed an obvious option – modify the IS service to explicitly set a return the desired codes and messages instead of simply throwing an exception which returns 500 by default. The wM IS BIS reference describes how to set the return code/message (a couple of ways to do it).

Hello Vallab,

Thank you again for your reply.That’s help me to fix the compilation error. But this made no change, I still get ‘500 Internal Server Error’ !

When i debug i find that the Context Message is not present in the pipeline. Do you know please what could be the issue here ?

BR

Hi Ahmed,

Please share the code you tried. Also I recommend that you could download the package shared and follow the steps in Invoke webMethods IS policy in API Gateway 10.1 and below (link already shared in prev comment from me) to get a hands-on with how to do programming using MessageContext (if not already done).

If you are using MessageContext coding in later versions (10.3 or above), you could configure “Comply to IS Spec” policy configuration as “False”. More details can be found here Invoke webMethods IS policy in API Gateway 10.2

Regards,
Vallab.

Hello Vallab, Raemon,

Thank you a lot for your help.

For more explanation :
we are using API Gateway version 10.7.
I use to invoke IS Service in request stage …
Even using “Comply to IS Spec” as “False” the Message Context still not added in the pipeline during execution.

Maybe it need some fix to apply ?! anyway for the moment i’ll adapt this customization to not use Message Context and keep the error 500 …

Thank you again for your help.

BR

Did you try using the output vars instead of relying on the message context? Don’t throw an exception. Instead, if steps in the IS service throw an exception, catch it and return the appropriate/desired status code message using the defined output vars in the spec.

Exploring this a bit further, what is the rationale for enforcing “business logic” in the API Gateway? Shouldn’t the native service be doing that? Sometimes we have to do things “in the middle” because the endpoint cannot be touched, but in general the endpoint should enforce data rules not the gateway.

Don’t give up on this. This can be done. If you can share more detail about the API GW policies and the native service (without exposing sensitive info) the community should be able to help. I noticed that you marked an answer as accepted, but based upon what you’ve posted, that did not address what you are trying to do. That may mislead people who come across this thread in the future.

Hello Reamon,

Yes i’ve tested values in output directly but it doesn’t work. I did this in request stage where there is no output as response code and response message.

in the IS service it seems that exception message is the last things that a service can return.

So I marked the Vallab reply as accepted because it’s correct the first purpose for me. But i’ve to move forward and give my customer a solution very soon, so i tried another approach that work good : instead of throwing exception in the IS service to reject the request i’ll let the native service do that by changing authorization value in the request header…

Thank you again

BR