API Gateway 10.15 | Usage Notes
 
Usage Notes
This section provides any additional information you need to work with the current release of this product.
*Before using API Gateway, consider the following points:
*API Gateway package in Integration Server cannot co-exist with the WmMediator or WmCloudStreams packages. WmMediator and WmCloudStreams packages must be disabled for API Gateway to function properly.
*webMethods API Gateway combines current webMethods Enterprise Gateway and webMethods Mediator capabilities in a single product. API Gateway offers the same capabilities within a simplified architecture. It also removes the dependency on CentraSite for API definition and policy definition.
*API Gateway comes in two editions. The Standard edition allows users to define threat protection policies and provides analytics for threat protection use cases. Typically, Standard editions are deployed in DMZ.Full edition supports all use cases of Standard edition, supports managing APIs, consumer applications, API-level policies, and managing API packages and plans.
*When API Gateway and API Gateway Data Store are already running and IP address is changed, connection between API Gateway and the Data Store is lost. Restart the API Gateway Data Store to reconnect to API Gateway.
*API Gateway uses the pub.client:http IS service to invoke HTTP based services.
*An Integration Server property 'watt.net.http401.throwException' allows the pub.client:http service to throw NetException for a 401 Unauthorized response from native service. This property was by default set to 'true' in Integration Server (in the Integration Server Administrator, go to Settings > Extended link). As a result, the response from API Gateway did not include the native service response body in case of 401 responses from native service. Beginning with API Gateway version 10.3, the watt.net.http401.throwException property is by default set to ‘false’ in Integration Server. Now, the pub.client:http service will not throw a NetException for 401 unauthorized responses from the native service. API Gateway will receive the 401 response body and send the native API provider's fault content (if available) to the application if the Send native provider fault option is enabled in API Gateway (in the API Gateway user interface, go to Username > Administration > General > API fault).
*An Integration Server property 'watt.net.http501-599.throwException' allows the pub.client:http service to throw NetException for a HTTP response status code that varies from 501 to 599 from native service. This property was by default set to 'true' in Integration Server (in the Integration Server Administrator, go to Settings > Extended link). As a result, the response from API Gateway did not include the native service response body in case of 501 to 599 responses from native service. Beginning with API Gateway version 10.3, the'watt.net.http501-599.throwException' property is by default set to ‘false’ in Integration Server. Now, the pub.client:http service will not throw a NetException for HTTP 501 to 599 responses from the native service. API Gateway will receive the 501 to 599 response body and send the native API provider's fault content (if available) to the application if the Send native provider fault option is enabled in API Gateway (in the API Gateway user interface, go to Username > Administration > General > API fault).
Note: These configuration changes may negatively impact any webMethods product instance, which is installed with an instance of Integration Server on which API Gateway is running. Software AG recommends that you use an instance of Integration Server dedicated for API Gateway.
*Do not provide values starting with a dot(.), in any of the fields in API Gateway UI and in key values when making API calls from a REST client.
*Enabling tracer for APIs stores cache every two hours post startup. This may cause spikes in memory usage, leading to API Gateway availability issues. To resolve this issue, upgrade to 10.15 Fix 6 or latest available fixes. If you are in a fix level below 10.15 Fix 6, use the tracing functionality cautiously; disable when it is not required. For extended tracing and an improved Gateway performance, upgrade to 10.15 Fix 6 or latest available fixes.