Hi All,
When calling External REST APIs, external parties may provide different endpoints for different environments.
Example:
CFG
cfg.abc.com
UAT
uat.abc.com
PRD
prd.abc.com
So when testing in CFG we configure external url ‘cfg.abc.com’ .
This means we have to reconfigure workflows after pushing changes to UAT and PRD.
What is the current practice in your projects?
Do you un-deploy workflows and change APIs, user, password etc. for authorization in UAT, PRD?
Solved
IFS Cloud 24R1 - Calling external REST APIs via workflows
Best answer by Lahirumala de Mel
From 24R2 release, along with oAuth capability in IFS REST Task, it comes the possibility to externalize URLs. You can parameterize the URL and set a value to the parameter in a different page outside of the Workflow designer, known as ‘IFS REST Task Configurations’. You can set this parameter to ‘cfg.abc.com’ in CFG env and ‘uat.abc.com’ in UAT env. And this table won’t clone even when the environment is cloned. So the URLs you provide won’t replace in cloning process.
You can store these changing variables in a configuration table (You will have to have an entity for this table). Use these changing values as workflow parameters. Load the data at the beginning of workflow from that entity using a projection delegate. This way, for each environment, the configuration table will have environment specific data and workflow will work without any issues.
This is just a suggestion and any other suggestions are welcome!
1 person likes this
+7From 24R2 release, along with oAuth capability in IFS REST Task, it comes the possibility to externalize URLs. You can parameterize the URL and set a value to the parameter in a different page outside of the Workflow designer, known as ‘IFS REST Task Configurations’. You can set this parameter to ‘cfg.abc.com’ in CFG env and ‘uat.abc.com’ in UAT env. And this table won’t clone even when the environment is cloned. So the URLs you provide won’t replace in cloning process.
Thanks
How about the user and password for basic authorization?
Are these supported as well?
Hi
I would NOT do this as a configuration. Reason being , I do not want to expose user, password, or client secret from client OR database.
If we need to follow that approach then all those attributes should be obfuscated and then it will become a MOD.
I think a better approach is to follow the process described by
+7If you are using headers to set username and password, they can be externalized as well using the ‘Free Text’ type IFS REST Task Configurations.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.