Product/components: Software AG designer 10.15 & API Gateway
Detailed explanation of the problem:
I created a flow service in the designer, and I want to use it in the API gateway as a routing custom extension or request processing “invoke”
But once i try to add the service in the IS field, I get an error:
Unable to process the PUT request for apis. An error occurred while processing the payload. Error message:
Error occurred while validating the correctness of the policy action: Custom Extension. Reason : Please check whether the webMethods IS service - XXX used in the policy action is available in the system
If i try to add the pub.flow:debugLog service, it works correctly.
I double checked the name of the service and full path, and its correct.
I looked in documentation and online for an answer but i cannot find anything helpful
Error messages:
Saving API failed.
(Routing Policies => Custom Extension) Unable to process the PUT request for apis. An error occurred while processing the payload. Error message:
Error occurred while validating the correctness of the policy action: Custom Extension. Reason : Please check whether the webMethods IS service - XXX used in the policy action is available in the system
@Hamzeh_Muaz Can you add snap shot of you custom extension policy . Based the error message to me it looks like service is not exist in the target system it could be a typo or you missed to add the service
Note : When you call a flow service from custom extension it should be as like below
Hi @Hamzeh_Muaz Based on the error message its clear that APIGW was not able find the flow service. Basically fully qualified namespace of the flow service is incorrect. In designer right click → Run your flow service in Browser and configure the same endpoint to custom extension flow service
I have fixed it as you said, to:
“ip:port/folder.folder/service”
but its still the same error.
Is there a step that i am missing? maybe from designer side to make the service exposed?
To run an IS service in this manner, the service must be available in the IS instance where API GW is hosted. That means when specifying the service in the policy it is just the fully-qualified name of the service. No http, no invoke, etc. Just the service name. You don’t get to call arbitrary end-points on arbitrary hosts for this – it is all “local.”
The online help has info. apigatewayui/help/index.html#page/API-gateway-ca-onlinehelp%2Fre-requestproc_invoke_wmis.html%23
Define the Integration Flow: Determine the sequence of steps and actions that need to occur for the integration to take place. This may involve transformations, validations, or enrichments of the data being passed between the API Gateway and backend systems.
IMO, most of these things should not be done in API Gateway. Validations, maybe (I’m not a fan of validation “in the middle”). Transformations, so-called “enrichments” (a fancy term for “go read more data from somewhere else”), and other non-trivial steps/actions should be elsewhere.
Of course this is just one view of how API gateways (in general) should be used – just making sure we know who is calling, allowing them to call only what they are allowed to, logging activity, etc. Transformations and other “heavy lifting” delegated to something better suited for that.
Certainly others may have different views on this.
Please share more information about your environment. Is the service you’re trying to call hosted on the same Integration Server Instance on which API Gateway is running? Not just the same machine, but the same JVM. If not, you can’t call it this way.
Share an updated screen shot of the policy properties.
In your original post you state " I want to use it in the API gateway as a routing custom extension or request processing “invoke”". Can you share details about what specifically is needed that leads you to want to use an extension or manipulate the request?
I’m not experiencing this issue, but the whole question brings me some questions.
I’m testing the API Gateway, and I was expecting to have the possibility to reuse an existing IS, not being forced to have 2 IS runtimes (1 for APIGW and another for “traditional” IS). Do you know if that’s possible?
Let’s say I have some “old fashion” IS services, exposed as SOAP and want to expose them in the APIGW, with associated plan and policies. Do I need to recreate the same services on APIGW IS?
It is possible but I would not recommend it. Pretend that API GW does not run on top of Integration Server. IMO, it barely does so anyway – GW is not really a “native” IS component, it has been “bolted” on.
No. On API GW, you define/“declare” the interface and route calls to the “native” component. The “native” component can be just about anything accessible via HTTP. Your “old fashion” components on an IS included.
GW is a “traffic cop.” Is the caller allowed? To which “native” components do the callers get routed? While the GW instance can do some level of work (request and/or response manipulation) or call services hosted on the GW IS as “native” endpoints, or create so-called “mash ups” there is a school of thought that this should be kept to a minimum in GW. The “heavy lifting” of transformations and such would be elsewhere, keeping GW as a thin passthrough, providing mostly security and logging. And when coupled with Portal, applications that want to be clients to APIs accessed via GW can see what the APIs are and request access. The real work of the API is done in the native enpoints, not in GW.
