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.
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?)
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).
@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.
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).
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 …
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.
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…