Microgateway 10.7 | webMethods Microgateway Help | Asset and Configuration Provisioning | Asset Provisioning
 
Asset Provisioning
Provisioning assets in Microgateway makes assets available for use in Microgateway. The assets you can provision in Microgateway are, APIs including policies and policy properties, API scopes, runtime aliases, applications, and global policies.
Note:
Microgateway only supports the REST APIs and do not support the SOAP and OData APIs.
Asset provisioning in Microgateway covers the following:
*Reading APIs, API scopes, policies, aliases, and applications from API Gateway on Microgateway start
*Updating APIs, API scopes, aliases, and policies from API Gateway
*Updating Applications from API Gateway
*Reading APIs, API scopes, policies, aliases, and applications from a file system by importing an asset archive
*Reading administrative settings from API Gateway
Note: 
*Only simple aliases, endpoint aliases, and HTTP transport security aliases are supported in Microgateway.
*If an API has an unsupported policy the provisioning of the API is rejected.
*If a global policy references an unsupported policy property then, the provisioning of the global policy is rejected.
You can provision assets to a Microgateway in one of the following ways:
*API Gateway asset archive-based provisioning
*Pulling assets from API Gateway
Microgateway also supports a mixed provisioning. Asset archives are preferred over the assets being pulled from an API Gateway when there is duplication of APIs.
Alias Provisioning
Simple aliases, Endpoint aliases, and HTTP Transport Security aliases can be configured in one of the following ways:
*By API Gateway asset archive-based provisioning, where the asset archive file exported from API Gateway contains the aliases in API. Microgateway, on startup, imports the aliases from the archive file and replaces all the aliases found in the APIs.
*By configuring the alias values in the custom settings file that is passed as an argument using the -c option during Microgateway startup.
A sample workflow that explains alias provisioning by passing the custom settings YAML file using the -c option during Microgateway start up is as follows:
./microgateway.sh downloadSettings -gw hostname:port
–-output my-custom-settings.yml

./microgateway.sh createInstance –instance MyInst.zip
–-config my-custom-settings.yml

unzip MyInst.zip –d /tmp/inst

/tmp/inst/microgateway.sh start –c my-custom-settings.yml
The aliases provided in the custom settings YAML file take precedence over aliases defined in the archive for aliases that have the same ID. A sample custom settings YAML file is as follows:
aliases:
petstore_host:
type: simple
value: petstore.swagger.iov2
petstore_endpoint:
type: endpoint
endPointURI: http://petstore.swagger.io/v2/pet/4
connectionTimeout: 30
readTimeout: 30
suspendDurationOnFailure: 0
optimizationTechnique: None
passSecurityHeaders: false
keystoreAlias: ''
BasicAuth_Custom:
type: httpTransportSecurityAlias
authType: HTTP_BASIC
authMode: INCOMING_HTTP_BASIC_AUTH
httpAuthCredentials:
userName: Administrator123
password: manage
domain: null
BasicAuth_Incoming:
type: httpTransportSecurityAlias
authType: HTTP_BASIC
authMode: INCOMING_HTTP_BASIC_AUTH
JWT_Outbound:
type: httpTransportSecurityAlias
authType: JWT
authMode: INCOMING_JWT
Oauth_custom:
type: httpTransportSecurityAlias
authType: OAUTH2
authMode: INCOMING_OAUTH_TOKEN
oauth2Token: 407e5c8d33c54c57bc7932bf5e803979
Oauth_incomingToken:
type: httpTransportSecurityAlias
authType: OAUTH2
authMode: INCOMING_OAUTH_TOKEN
Endpoint configuration through aliases
For a Microgateway server to run in a Kubernetes sidecar environment, the hostname of the native service URL must be changed to localhost. The most convenient way is to use aliases for the respective Routing policy. Hence the API in API Gateway should use either a Simple alias or an Endpoint alias.
The alias value is included in the config.yml configuration file. You have to configure the alias name and the type, which are mandatory.
Example where API Gateway uses a Simple alias.
Name = “MySimpleAlias”, Value = “myhost”
Overwrite the alias value as follows in the config.yml file and start Microgateway.
…
aliases:
MySimpleAlias:
type: simple
value: localhost
Example where API Gateway uses an Endpoint alias.
Name = “MyEndpointAlias”, Endpoint = “http://myhost:1234/service”
Overwrite the alias value as follows in the config.yml file and start Microgateway.
…
aliases:
MyEndpointAlias:
type: endpoint
uri: http://localhost:1234/service
These alias values can be used with the generic Microgateway environment variables in the format mcgw_aliases_name_propery = "value" .
For example, the endpoint alias with the URI http://localhost:1234/service is specified in the environment variables as follows:
mcgw_aliases_MySimpleAlias_type = "endpoint"
mcgw_aliases_MySimpleAlias_uri = “http://localhost:1234/service”
Asset Provisioning through the API Gateway Asset Archive
You can start the Microgateway server with one or more API Gateway asset archives exported that contain the assets to be provisioned. Microgateway supports archives exported from version 10.3 or higher. All the supported assets are imported during Microgateway startup.
You can pass on the API Gateway asset archive in the start command through the archive parameter:
./microgateway.sh start -p 9090 --archive apigw_archive.zip
You can specify multiple archives using a comma separated list. Ensure that there is no space within the comma separated list.
./microgateway.sh start -p 9090
--archive apigw_archive1.zip,apigw_archive2.zip
The Microgateway reads the archives in the specified order. If there are any assets provisioned by an earlier archive, they are overwritten by the assets present in the later archives.
Creating API Gateway Asset Archives using the Command Line
You can use the createAssetArchive command that Microgateway CLI provides for creating an asset archive. The command takes the parameters detailed in the Command Line Reference.
A Sample workflow for Asset Provisioning using Asset Archive
A sample sequence for asset provisioning by importing the package looks as follows. A sample archive EmployeeService.zip is used to describe the example.
1. Start API Gateway with the given archive EmployeeService.zip
./microgateway.sh start -p 9090 -a /tmp/EmployeeService.zip
2. Check status of the Microgateway instance.
GET http://localhost:9090/rest/microgateway/status
The status response looks like this:
{
"description": "webMethods Microgateway",
"publisher": "Software AG",
"version": "10.4.0.0"
}
3. Retrieve details about the deployed APIs, applications, and global policies using the following request.
GET http://localhost:9090/rest/microgateway/assets
The details display the provisioned APIs.
4. Invoke the Employee API.
GET http://localhost:9090/gateway/EmployeeService/employees
5. Stop the Microgateway listening on port 9090.
./microgateway.sh stop -p 9090
Pulling Assets from API Gateway
You can start the Microgateway server with a URL and credentials pointing to an API Gateway. Microgateway pulls the assets from the referenced API Gateway.
Microgateway can only pull assets from API Gateways with version 10.3 or higher. Multiple Microgateways can pull assets from the same API Gateway. To pull assets from API Gateway, use the Microgateway start command with the required command line options detailed in the Command Line Reference.
Connecting to API Gateway
Microgateway connects to the API Gateway during startup. If the API Gateway can't be contacted, then Microgateway terminates with an error message as follows:
Start of process failed :
>>> Microgateway server not started <<<
Error during startup: API Gateway not active or accessible: status 503,
errorMessage: server is not active
Pulling Specific Assets
An API, policy or application is identified either using its unique identifier or by the combination of name and version. If an asset name or identifier can't be resolved, a respective error message is written to the Microgateway log.
For an identified API, the API along with the API-level policies and policy properties, registered applications, and referenced runtime aliases are pulled from API Gateway.
For an identified global policy, the policy, the policy properties, and referenced runtime aliases are pulled from API Gateway.
For an identified global application, only the application is pulled. For runtime aliases, the default values become effective.
If you do not specify an API, application or policy, then no assets are pulled from the API Gateway.
Note: 
*If an API has a unsupported policy, the provisioning of the API is rejected.
*If a global policy references an unsupported policy property then, the provisioning of the global policy is rejected.
*When provisioning runtime aliases the default values become effective.
A Sample workflow for Asset Provisioning by pulling from API Gateway
The following sample sequence shows the flow for provisioning APIs by pulling from API Gateway. It assumes that the API Gateway holds 2 REST APIs: EmployeeService and EmployService2.
1. Start Microgateway with given a API Gateway URL and API name.
./microgateway.sh start -p 9090
-gw localhost:5555 -gwu Administrator -gwp password
-apis EmployeeService
2. Check the deployed assets.
GET http://localhost:9090/rest/microgateway/assets
3. Call the API.
GET http://localhost:9090/gateway/EmployeeService/employees
4. Stop the Microgateway listening on port 9090 .
./microgateway.sh stop -p 9090
5. Start Microgateway with given a API Gateway URL with multiple API names .
./microgateway.sh start -p 9090
-gw localhost:5555 -gwu Administrator
-gwp password -apis EmployeeService,EmployeeService2