The Gateway Management API (GMAPI) generally runs operations against a local or remote Gateway database to create, read, update, or delete policies, services, identity providers, cluster-wide properties, and many other aspects of the Gateway's deployment from a programmatic or command-line interface. This allows customers to interact with the Gateway without requiring access to a GUI-based system. The GMAPI can allow system adminstrators to automate or cron jobs that may occur regularly or without human intervention. It can be used in lieu of the Layer 7 Policy Manager for all of the aforementioned functions. For a specific list of functions, seek out the Gateway Management Client documentation for the respective version of the Gateway.
Services
Creating and updating services is typically done with pre-made services created in other environments via the Policy Manager, or with changes to existing services. It is not recommended that services be authored by hand and then imported into the Gateway via the GMAPI. As such, an example service XML is not provided.
Enumerating/listing existing services
This will provide the user with an XML file containing all published services on the Gateway. This does not include policy fragments or internal-use policies. ./gatewayManagementClient.sh <gateway hostname> enumerate -type service -username <user> -password <password> -skipVerifyCertificate [-outFile <path to XML file>]
Reading specific services
This will display the XML for a specific service policy and optionally output it to a local file. ./gatewayManagementClient.sh <gateway hostname> get -type service -username <user> -password <password> -skipVerifyCertificate -id <oid> [-outFile <path to XML file>]
Delete existing services
This will remove a specific service policy from the Gateway, irrevocably. ./gatewayManagementClient.sh <gateway hostname> delete -type service -username <user> -password <password> -skipVerifyCertificate -id <oid>
Updating existing services
This will update a specific service policy on the Gateway using a local XML file as the source. ./gatewayManagementClient.sh <gateway hostname> delete -type service -username <user> -password <password> -skipVerifyCertificate -id <oid> -inFile <path to XML file>
Creating new services
This will allow the user to create a new service with a policy from an existing file. ./gatewayManagementClient.sh <gateway hostname> create -type service -username <user> -password <password> -skipVerifyCertificate -inFile <path to XML file> -outFile <path to XML file> ?
?
Cluster-Wide Properties
Cluster-wide properties can be created or updated using flat XML files. To create a new cluster-wide property, it is recommended that you enumerate all or get a specific cluster-wide property and modify it to your needs. When creating or modifying properties, be sure to modify the Name and Value elements as well as remove the id parameter from the ClusterProperty element.
This will display the all existing cluster-wide properties in XML and optionally output it to a local file. ./gatewayManagementClient.sh <gateway hostname> get -type clusterProperty -username <user> -password <password> -skipVerifyCertificate [-id <oid> | -name <name>] [-outFile <path to XML file>]
Delete existing properties
This will remove a specific property from the Gateway, irrevocably. ./gatewayManagementClient.sh <gateway hostname> delete -type service -username <user> -password <password> -skipVerifyCertificate -id <oid>
?
Updating existing properties
This will update a specific property on the Gateway using a local XML file as the source. ./gatewayManagementClient.sh <gateway hostname> delete -type service -username <user> -password <password> -skipVerifyCertificate -id <oid> -inFile <path to XML file>
Creating new services
This will allow the user to create a new property on the Gateway from a local XML file as the source. ./gatewayManagementClient.sh <gateway hostname> create -type service -username <user> -password <password> -skipVerifyCertificate -inFile <path to XML file> -outFile <path to XML file> ?
?
Folders
The folder structure within the Gateway is hierarchical, with each folder referencing a parent folder in its declaration. In the below example, you will see that ?root node (or ?/?)? has an ID of ?-5002?. This is a static value and all root folders will have this ID. The next level (?Level 1?), has a ?folderId? of -5002, indicating that it is a child folder of folder ?-5002?. ?Level 1? has its own unique ID, which other folders could use as its own parent identifier. ? When creating new folders, it is important to keep this relationship in mind. The Gateway will automatically map other relationships, but the newly created folder must have its parent relationship defined at creation time. Additionally, when creating new folders, omit the ?id? parameter from the XML document.