Best mechanism to expose wM.io Integration assets to wM.io API Gateway

, ,
1

Hi All,

What is the best option to choose and expose Rest API (Flow service)/ Rest API (Work Flow) from webMethods.io.Integration to webMethods.io.APIGateway ?

Thanks & Regards,
Jeevan

2

Hi,

You can use REST API Descriptor generated in webMethods.io to register in API Gateway.

3

Hi Srikanth,

Thanks for the quick reply . My concern is that " what is the best option to expose
Rest API (Selected Flowservice) or Rest API (Selected work flow service) to the webMethods.io.APIGateway from webMethods.io.Integration.

Thanks & Regards,
Jeevan

4

“Best” is a subjective term and requires criteria against which to gauge a possible solution.

If you’re just asking “how”, the docs describe how to define an API within Gateway. @srikanth.prathipati1803 provided a way.

If you really want “best” you’ll need to share much more information about the details of your components so that community participants can judge which option is “better” than another.

1 Like
5

@sagdeveloperjk
When i worked for Software AG, I created some training on webMethods.io Integration REST API builder. It covers two types of API design: Service-First and API-First API.

You can take it for free in the Software AG learning portal: https://learn.softwareag.com/

You need to register and login.
After login, select Catalog from the top menu.
You can select webMethods.io from the left nenu, and in the search field look for: REST

The course is:
webMethods.io Integration REST API Builder (CL617C07-75E)

Here’s the direct link to enroll:
https://learn.softwareag.com/enrol/index.php?id=1683
(you need to be logged into the learning portal to enroll)

Wayne

1 Like
6

Hi Wayne,

Sure I will go through the REST API Builder (CL617C07-75E) course.

Thanks & Regards,
Jeevan

7

A workflow doesn’t really have a service contract, so if you’re trying to expose a REST API, I’d always recommend a flow service, as your service contract (inputs/outputs) become the REST API definition.

Workflows are asynchronous by design also, and use a queueing mechansim. Flow Services by default are synchronous, so it’s also likely you’d get better performance from a Flow Service functioning as a REST API that a workflow.

But as @reamon states - best depends on really what you’re trying to achieve here.

1 Like
8

Hello @wayne.leishman.20059

And which Outbound Auth Transport policy we must use to route the calls from API GW to wM.io Integration?
Only Basic Auth can be used?

This is not described in the trainning.

Does it have to be by creating a user in wM Cloud, instead of being able to define a technical user with different policies (For example: password expiration)?

9

wM.io integration REST APIs by default are secured by basic auth, but you can also use OAuth2 ( OAuth 2.0 - webMethods.io Integration) and MTLS/2-way-ssl ( Two-Way SSL - webMethods.io Integration).
If you want to connect a REST API to the gateway, and are using the default basic auth, then you need to add an outbound auth - transport policy.

You’ll see in the screen shot below this is using an alias in this example, but could equally be OAuth2.

In the case of basic auth, this does have to be a user defined in SAG Cloud, which can be configured accordingly both in SAG Cloud and roles in integration.

image
image1560×986 96.8 KB

10

Hello @Dave_Pemberton Thank you for your reply. It has helped me a lot!

What if I focus the question only on SOAP API? (Basic Auth)

If I understand correctly, your answer, I should create a user in wM Cloud. Users use globally the Password expiration period policy.

It means that if I want to expose a SOAP API from Integration to API Gateway, I will need to eventually update the password of the user created for this interaction every n days defined in the Password expiration period policy.

Is this correct?
Is there no way to create some kind of administrator or technical user with different policies, or a better way to connect both components?

11

Right now for SAG cloud users you cannot differentiate a password policy individually, so if you do have a password expiration set, then yes, you would have to update the password in the gateway periodically. In my example, I used an alias, and can update the alias relatively easily (and via APIs), without having to modify the API in the gateway. This also allows for per environment configurations to have a different user in dev vs test vs prod.

We are working through the interactions between the Gateway and integration currently, with a plan to make the interconnection between these more seamless. A small number of changes will start to appear in the next release with ‘private’ APIs that aren’t publicly callable through integration, and will have more in coming releases.throughout 2024.

12

Hi @Alejandro.Giralda
Sorry, I missed this thread.
We had planned to create service accounts in the Software AG Cloud Administration page. These users are stored in our identity management solution. HOWEVER, we ran into the password expiry policy.
Due to the password expiry policy in SAG Cloud, we are started using the aliases in wM.io API gateway to define service account.
As @Dave_Pemberton said, you can then assign different passwords to the service account in each environment. But the big factor was there is no password expiry policy in API gateway.
We look forward to the upcoming features that Dave mentions to define “private” APIs.

13

Thanks to both of you, @Dave_Pemberton and @wayne.leishman.20059

I look forward to the new capabilities that will be included in the cloud solution.

Best regards and thank you again.

1 Like
14

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.