As the use of SnapLogic's API Management functionality widens, more businesses and organizations are finding the API portal a useful place to not only publish APIs that are created within the Platform, but also to publish and create their catalog of external or proxy APIs in their ecosystem. Particularly with organizations that have developed microservices supporting their initiatives prior to adopting an Integration Platform, not every API creator may have be a SnapLogic Integrator. Common to these external microservices or third party services and the integration APIs developed with SnapLogic pipelines is an entire lifecycle, typically supported by DevOps procedures, tools, and automations.
Take for example a legacy microservice that might control the stepper motor of a security camera. This isn't specifically an app or data integration service, but it exposes an API to send a signal to a device. SnapLogic can easily manage that microservice's API as a proxy inside APIM, and integrators can discover and learn about that API inside the catalog. Should the manufacturer update the firmware for the camera and provide an updated API to be used, with the SnapLogic Public APIM APIs, the DevOps team could write a script to both update each device's firmware and at the same time manage the API documentation and definition inside SnapLogic APIM. Without these APIs, the deployment team might incur the overhead of coordinating the update of the API definition manually.
The APIs available also provide functionality to migrate both SnapLogic APIs and Proxy APIs. If the integration team works with a DevOps team to move items from Dev to Test to Prod, or perhaps from region to region, the Public APIs make this fast and easy.
To support learning about the Public APIs, and for teams to test them out, we've created a collection of the Public APIs attached to this post. Each example is completely parameterized, and each example has a Postman Environment that accompanies it. By loading an API in Postman and configuring its corresponding environment, integrators or engineers can quickly build examples that they can leverage in their organization.
Installation
The file attached can be unzipped to a personal workstation, and a Postman user can create a new workspace. In that workspace, there will be an import button where the user can select the collection and all environments in one fell swoop.
Once that's completed, both the collection of APIs and the environments will be available from the left navigation bar.
Preparation
Once the environments are loaded, there is a Global Environment that needs to be created and configured for the entire collection. Add the following to your Postman Global Environment:
-
user (IIP Administrative User)
-
password (IIP Administrative User)
-
pod_path (domain - typically elastic.snaplogic.com for North America)
-
environment (what was once the org name in the URL for IIP)
Once configured, your Global Environment will look similar to the image below.
Using the Collection
Once the global environment is configured, what remains is configuring the values in the environment for the specific API being tested, and then opening the API and setting its environment to the one just configured.
As an example, an integrator may already have a set of SnapLogic pipelines in a project that are intended to be available as APIs in APIM for use across the organization. The first step in this process is to fill out the variables for their project in the proper Postman environment. In the collection attached to this post, each request in the collection will have a corresponding environment. For the request Create APIM from SL Project, the corresponding environment is also called Create APIM from SL Project.
Once the variables are configured in the environment, prior to testing the given API, ensure that the configured environment is applied to the request. That's accomplished by using the selector on the request in the upper right corner.
Once the environment is configured and applied to the request, the "Send" button can be used to execute the request. This collection can be used now for both testing the Public API, and integrators can use the variable configurations to help their DevOps teams best develop their automations for managing their legacy microservices along with the modernized SnapLogic APIs.
1 Comment
