The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Cisco Hosted Collaboration Mediation Fulfillment API Gateway Proxy uses unique URLs to identify each routable application. URL query parameters are used to identify the node that is to receive a request.
The following is an example URL: https://example.com:8443/APIGatewayProxyWebService/proxy/cucm/soap/axl/?customer-name=ABC&cluster-name=Cluster-1
Clients do not usually have to create these URLs. A list of the URLs is available from the Application Reference Directory.
The host portion example.com:8443 identifies the routable address of the Cisco Hosted Collaboration Mediation Fulfillment. This will be taken from the global address and port configuration. See Global Address and Port Configuration.
The path parameters - /APIGatewayProxyWebService/proxy/cucm/soap/axl/ - identify the service.
The query parameters wsdl&dm-name=vm-gateway also referred to as the routing parameters, identify the actual routable application.
Example URL: https://192.16.8.10:8443/APIGatewayProxyWebService/proxy/cucm/soap/axl/? customer-name=ABC & cluster-name=Cluster-1
The routing parameters vary based on the type of application to which the API Gateway Proxy is routing requests.
Note | If the routing ID is provided in the URL along with the Shared Data Repository hierarchy or names, routing ID takes precedence and the request is routed based on the routing ID. |
Cisco Hosted Collaboration Mediation Fulfillment Services: Shared Data Repository, HLM, Fulfillment, Service Inventory.
Routing parameters are not applicable.
Configuration information is provided to developers for context in case they need to contact Cisco Hosted Collaboration Mediation Fulfillment administrators to troubleshoot API issues.
For more information see http://www.cisco.com/en/US/partner/products/ps11363/prod_maintenance_guides_list.html
For routing to work, each application must be configured properly in the Shared Data Repository. The API Gateway Proxy will route to:
If routing is based on routing ID, each application should have a routing ID. See Routing ID Configuration
If routing is based on routing ID, each application should have a routing ID. See Routing ID Configuration
Cisco Hosted Collaboration Mediation Fulfillment – No configuration is required for routing to Cisco Hosted Collaboration Mediation Fulfillment.
Only properly configured applications are routable. Once an application is properly configured, its unique URL and link to specifications will display in the Application Reference Directory.
By default, Cisco Hosted Collaboration Mediation Fulfillment will use hierarchical name-based routing that is based on the infrastructure configuration in the Shared Data Repository. If a partner decides instead to use a unique identifier based on information that is already within their provisioning system, they can configure a routing ID. Routing ID is an optional field that can be configured as required.
The routing ID can be configured through the Cisco HCM-F GUI or Cisco HCM-F Web Service Interface. If a routing ID is configured for an application, its unique URL (in the Application Reference Directory) is built using the routing ID.
When the global address is configured, it will be used with the global HTTPS port when we advertise URLs in the Application Reference Directory. This allows clients to communicate with the API Gateway Proxy using an address that is routable from the client network.
When a client creates a subscription that may trigger asynchronous notifications, the API Gateway Proxy overwrites the notify-to address of the client with that of the global address. This is currently the only scenario where the global HTTPS port is used, since the notifications will be HTTP messages. This way, notifications are delivered through the API Gateway Proxy.
Clients re-use connections when communicating with the API Gateway Proxy.
Clients enable cookies, and re-use http sessions when communicating with the API Gateway Proxy.
Clients must ensure that all parts of the URLs they use to communicate with the API Gateway Proxy are configurable. This includes the hostname, port, and paths.
That a DNS be available to speed the establishment of new sessions between the API Gateway and Management Components.