API Connect

Hi Kashif,

By connection policies, I assume you are talking about a proxy server that is an intermediary server to get you out of your intranet to your actual backend?  In a MultiProtocol Gateway in DataPower you would specify that on your User Agent associated with the service's XML Manager.  Where in DataPower are you manually entering this information for the API Gateway today but "it cannot be saved"?

If I'm right about what you are requesting, I believe this proxy server designation within an API Gateway invoke policy is on the development roadmap but has not been implemented yet (no promises as to when it will be, sorry).  However, if you're willing to use a v5 emulated user defined policy, you would need to do some coding for that v5 UDP where either a GatewayScript or Transform (XSLT) MPGW Processing action would do a urlopen to your backend server url, and the webapi User Agent (part of the v5 emulation framework) would need to be overridden to specify the proxy server policy that matches that backend url to the proxy server hostname that is desired.  The v5 user defined policy zip file would need to be included into a gateway-extension zip file that is associated with the API Gateway in CMC.  Also to this  gateway-extension.zip file would be have added a .cfg version of the webapi user agent object which would also be zipped into the gateway-extension.zip, and finally the gateway-extension.zip file's manifest.json file would need to reference both of these zip files.  I understand it is some work on your part but that is the only way I can see this being workable until that enhancement is implemented in the API Gateway invoke policy. 

Best Regards,

Steve

Hi Kashif,

My apologies, my information on this feature is out of date and you can ignore my previous post.  Support was added to the DataPower API Gateway object (which is where I'm sure you're doing your manual addition) to specify this connection policy, but it was not exposed to the API Manager UI as I thought it might be, thus I didn't know the feature had been delivered.  I'd assume this was considered an "advanced" feature that could only be specified by using a gateway-extension.  So you'd need to add to an existing gateway-extension.zip (or create a new zip)  a zip with a .cfg file that would add just these proxy server policies to your API Gateway object.  The problem with manually updating them is that they are not persisted.  The gateway-extension zip file provides the mechanism to persist them.  So as an example, you would create a file named proxy-servers.cfg which would have something like

top; configure terminalapigw apiconnect  proxy */proxiedurl* off remotehost 9999 username passwordalias  <you can have multiple proxy commands if more than one matching url>exit

assuming your API Gateway was named apiconnect.  For the proxy command, note that passwordalias is a Password Alias object reference.  If your appliance is a physical or virtual appliance, you should be able to create that manually and it will persist, then you simply would reference it as above.  If this is a k8 pod I don't believe it would be a good idea to add that here as I'm sure you would not want this to have the .cfg file with a password in the clear.  I'll see if I can get some help here as to how to get that password alias object created in a pod that would provide more security around that password, perhaps the DataPower operator could be used, but I'm not as familiar with the k8 environment.

Zip the proxy-servers.cfg file into proxy-servers.cfg.zip, then add that zip file to your existing (or new) gateway-extension.zip file.   Then add to your manifest.json file that is also in the gateway-extension.zip file an entry into the files array such as:

{    "extension": {        "files": [            {                "filename": "proxy-servers.cfg.zip",                "deploy": "immediate",                "type": "extension"            }        ]    }}

Note that an existing manifest.json file can have other files and may have a properties section that would be used to specify which v5 emulated policies are to be deployed.

Finally, use CMC to add or update the gateway-extension with your gateway.

Best Regards,

Steve Linn

Hi Kashif,

By connection policies, I assume you are talking about a proxy server that is an intermediary server to get you out of your intranet to your actual backend?  In a MultiProtocol Gateway in DataPower you would specify that on your User Agent associated with the service's XML Manager.  Where in DataPower are you manually entering this information for the API Gateway today but "it cannot be saved"?

If I'm right about what you are requesting, I believe this proxy server designation within an API Gateway invoke policy is on the development roadmap but has not been implemented yet (no promises as to when it will be, sorry).  However, if you're willing to use a v5 emulated user defined policy, you would need to do some coding for that v5 UDP where either a GatewayScript or Transform (XSLT) MPGW Processing action would do a urlopen to your backend server url, and the webapi User Agent (part of the v5 emulation framework) would need to be overridden to specify the proxy server policy that matches that backend url to the proxy server hostname that is desired.  The v5 user defined policy zip file would need to be included into a gateway-extension zip file that is associated with the API Gateway in CMC.  Also to this  gateway-extension.zip file would be have added a .cfg version of the webapi user agent object which would also be zipped into the gateway-extension.zip, and finally the gateway-extension.zip file's manifest.json file would need to reference both of these zip files.  I understand it is some work on your part but that is the only way I can see this being workable until that enhancement is implemented in the API Gateway invoke policy. 

Best Regards,

Steve