In our Integration Server, there is a service located in package “testPackage”. If you explore the package’s services, you will find three services (made in form of Flow Services in Designer):
service:firstService
service:secondService (has a string input)
new:thirdService
Now if I want to invoke service:firstService in API Gateway… what do I insert into the webMethods IS Service (in Policies > Request/Response Transforming > Invoke webMethods IS, and in terms of secondService, I’d like the input to be taken from what was submitted from the user that made the request, like a JSON string), and what do I pick for ‘Run As User’?
Thank you. I just have no idea what to look for and what are some examples I could use.
depends whether you want to use direct invocation via pub.remote:invoke or if you want to use pub.client:http for web based invocation.
For both cases you should have a look at the IS Built-In-Services Reference Guide.
Regarding “Run As User”:
You can either use Administrator, of this is not suitable for you, you can create your own user and assign it to a custom ACL which in turn needs to be assigned to the service as ListACL and ExecuteACL.
Regarding “Run As User”:
You can first smoke test either use Administrator, or create custom user (with all proper entitlements - user roles/execute ACLs) before calling the IS service from AGW
That’s if we’re opening it in the browser. But what if we’re trying to put that in the API Gateway > API > Policy > Invoke webMethods IS > webMethods IS Service? Do we really just put the URL above wholesale? Or just say pub.client:http(https://integrationserver.com:5555/invoke/service/firstService)? I’d like to remind that the API Gateway and Integration Server are located in different locations, so I think the IS location must be put. But please correct me if I’m wrong.
You will need to replace the hostname, you can do this directly when creating the API, or you can do it via a routing rule in the policies tab. You can also replace the server name and port with an alias e.g. ${myIS}:{myISPort}/…
Integration Server is quasi compatible as API i.e. you could then define in your API any inputs as query params or provide a body. However you will have to define all of this from scratch in the API Gateway and then make sure that your API matches the required input signature of your service. In addition your API swagger will be missing any description of the output, unless you also create it manually.
As an alternative why don’t you create a proper API in your Integration Server, that way you don’t have to do anything on the API Gateway side other than map the host/port. You can even push the API descriptor direct from Designer or import it via a swagger or Open API 3.0 descriptor that you fetch dynamically from you Integration Server.
@John_Carter4 Thanks for the offer, but I don’t think I will be using this one on my project. My project isn’t a personal one but a joint one that required the usage of the API Gateway. That’s why I must learn about what is put in these:
API Details → Native Endpoint
Policies → Routing → Endpoint URL
Policies → Request Processing → Invoke webMethods IS → webMethods IS Service
All including their format and what must be put based on the information that existed in the Integration Server located in a different location than the API Gateway. So it’s not creating from scratch, but modifying what’s already existed.
Thanks for the offer, but I need to concentrate on those points I laid out. If you guys want to refer to the Reference Guide, please also mention at what page and what section. It’s a bit massive that I could end up looking at the wrong part of the guide.
To clear things up, I’ll try uploading screenshots of the parts I’m confused on what to insert.
NOTE: I removed ‘firstService’ from the URL, because this will be considered the resource which gets appended later.
You don’t need to set a request processing policy unless you want a different signature to your API from the underlying service.
Don’t forget to add a “Run as” policy under routing to ensure that you don’t have to expose users accounts of your IS to the outside world. You can use a more secure security policy in the API Gateway to then secure the API.
You will then have to edit the resources and methods manually for your API. Don’t forget that the resource name gets added to the end of the native endpoint, so you should create a resource called ‘firstService’ and then provide the necessary inputs as either query params or in the body if specifying a POST. This is where you could use a request transformation policy if you don’t want to expose the service name as the resource.
Also be aware that native integration service services can only be invoked either as GET or POST. DELETE, UPDATE and PATH are not supported unless using a proper API descriptor as I described before.
You don’t need to set a request processing policy unless you want a different signature to your API from the underlying service.
Actually, that’s what’s required in my task right now, so I cannot skip this one.
I need to find out a way to modify the data (JSON) given from the invoked Native Endpoint into some sort of XML, to be delivered to the Endpoint URL where it would invoke another service that only accepted XML, and then returned as JSON again to the user. I feel that the option would be about invoking webMethods IS in either Request Transformation and Response Transformation, but I don’t know what to type in that part in order to invoke the IS (located in a different server than the API Gateway). Just typing ‘service:firstService’ only worked if the API Gateway and IS Server is in the same place, but my current environment doesn’t give me that luxury, so I had to know whether ‘https://integrationserver.com:5555/invoke/service:firstService’ is what actually works, or I need to type something else.
Ah, I understand better now. I thought firstService was your endpoint!
You service has to be locally hosted if you want to call an IS service as a request or response transformer. You cannot provide a URL. In this case you need to use a custom extension instead and choose “external endpoint”
I would first experiment by making the service anonymous so you can call it without issue (i.e. click on permission of the service and set the execute ACL to Anonymous). I would the setup the service to trace or save the pipeline. That way you can debug the service with restorePipeline to see what you have to play with.
No problem,
You can do that in Designer from the properties panel of any folder or service. Setting the permissions at the folder level allows you to set permissions for all services below it unless they have a specific permission set i.e. not ‘inherited’.
e.g.
Don’t forget you can create your own ACLs via the admin portal and Anonymous is generally not a good idea. This is recommended for all services that are to be exposed to the outside world and you should also be aware that ACLs and their assignments are not persisted in the package but in the IS config directory.
That’s not an issue if you are using Deployer to move a package from one server to another. However, if you do it manually via export/import then you will need to recreate and reassign the ACL to the service. To automate you need to merge the files
config/acllist.cnf
config/aclmap_sm.cnf
lastly you can also change ACL assignments in the admin portal via
Admin → Packages → Management → Browse folders
Navigate to your folder or service and click on the execute ACL to change it.
