Usage of Flow Service/Invoke IS in API Gateway

, ,
1

Hello Folks

I am new to web methods platform & would like to understand the usage of flow services in API Gateway

  1. Is there any limitations of using flow services with in API Gateway (Deployed to IS server within gateway host)
  2. Should we restrain from using any functions is flow service while developing it for API Gateway
  3. Can we implement custom JWT , Encryption , Signing for payload or particular field within payload in API Gateway

Thanks

Product/components used and version/fix level:

Detailed explanation of the problem:

Error messages / full error message screenshot / log file:

Question related to a free trial, or to a production (customer) instance?

2

The flow service engine that’s embedded in the gateway is limited compared to the one you get in the full Integration Server / Microservices Runtime. You only get the WmPublic package and the API gateway package.
This is on purpose, because you should have a good separation of concerns between the API gateway tier and the Integration tiers.
The gateway flow service engine isn’t for application integration, it’s to implement things like custom authorizations or complex request/response transformations.
The JWT and encryption use cases you mention are indeed very good examples of things you can do with these flow services.
There should be no functional logic there, the gateway should remain (as much as possible) a dumb pipe.
Keep in mind the ability to implement and call flow services is limited to the on-premise (self-hosted) version of the API gateway. The iPaaS gateway does not provide this feature.
For more advanced use cases, the micro gateway also does not support the execution of these flow services.

2 Likes
3

In addition to the excellent guidance from @Stephane.TAILLAND_emp I would offer this guideline – avoid using FLOW services in API GW whenever possible. Auth, encryption, etc. – you should be able to do >95% of what you need in API GW console without needing to use custom code.

Stated another way, adding a custom FLOW (or Java) service in the “local” IS should be the very last resort, never the first option considered. Such components are sometimes needed but it should be very rare.

1 Like
4

Thank you very much @Stephane.TAILLAND_emp & @reamon for your inputs.

5

IMO, one should proceed with caution here too. Transformation is one of the core “application integration” activities, not so much a “gatekeeper” activity. Adding/dropping a header is okay (transport focus). XML to JSON and vice versa less so.