1. Enable access to a service with Secure Gateway

In this step, the first few instructions may seem familiar – you should be comfortable with navigating to and within an OpenShift web console in the IBM organization cluster based on your completion of the first Drone lab. As a reminder, you can always reference the first lab’s instructions guide here https://ielgov.github.io/dronelab1. In this lab, you will focus on a different cluster: one that emulates a real-life organization that has its own private service.

The purpose of this setup was to demonstrate the technology and value behind connecting various applications and services between different clusters, even if they are public or private. In a typical case, an application may want to access services that are located in a private cloud. With the inherit nature of private cloud, it may seem problematic to introduce communication with any public cloud application.

Let’s take a moment to review some concepts you will be delving into in the next few steps. Consider two parties involved: 1. the Operators that use the Remote Drone Operations Console application, and, 2. an organization, “GSC Drones-To-Go”, which has private on-prem resource in Coppell, TX that allows piloting and observing of local drones.

View full size diagram

GSC Drones-To-Go wants users like the Operators to access their drone service, wants to easily manage their access, and wants to make sure this connection is done securely so they aren’t compromised in any way.

The Operators, owners and users of the Remote Drone Operations Console, want to connect the service that GSC Drones-To-Go provides.

You will explore how IBM® Secure Gateway can help enable the connection between the Public Safety Situational Awareness Operator users in one cloud environment and the GSC Drones-To-Go services that are  running in another cloud environment. By deploying the lightweight and natively installed Secure Gateway Client, a secure, persistent connection can be established between your environment and the cloud. You can imagine the Secure Gateway Client is like an on-prem bouncer, checking who wants access based on their list.

Secure Gateway allows the safe connection of applications and resources regardless of their location. This is important - rather than bridging your environments at the network level like a traditional VPN, Secure Gateway provides granular resource control operating with the principle of least privilege as its core tenet.

In this step of the lab, you learn about how to use Secure Gateway to bridge connection between the Remote Drone Operations Console and the on-prem resource at GSC Drones-To-Go. In later steps, you will continue to get more access to the IEL Drone-To-Go service, including accessing APIs and even invoking related flows.

Reference:

1.1 Access IBM Cloud

Just like in the first lab, you’ll need to access RedHat OpenShift through the IBM Cloud in order to build and deploy your application. Begin by signing into IBM Cloud. ( New Tab ⇒ https://cloud.ibm.com ) (Single Sign-On Required with w3id)

Once you’ve logged in, you should be greeted with a dashboard that displays the various resources that IBM Cloud has to offer. From Cognitive APIs to DevOps to Classic Infrastructure resources, IBM Cloud has many offerings to explore. At the top of the dashboard, you’ll see a navigation bar. On the right side of the navigation bar, there is a dropdown for various accounts you may be a part of. Most likely, the default is the last account you opened, if not the only one available. For this lab, you’ll be working in the 1500867 – IBM account. Click on the 1500867 – IBM account in the IBM Cloud’s navigation bar dropdown.

1.2 Access RedHat OpenShift cluster

Once you click on 1500867 - IBM, your dashboard will update with Resources that are specific to it. You should see a Resource summary card that currently contains a Resource: Clusters. Click on View all in the Resource summary card.

You may recall that in Drone Lab 1, you accessed the mycluster-dal12-b3c.4x16 cluster, using it to deploy your remote drone operations console onto the public cloud. For the purposes of this lab, this mycluster-dal12-b3c.4x16 cluster will be referred to as “Cluster A”.

For most of this lab, you will be working with the droneLabs cluster, which may sometimes be referred to as “Cluster B” or “Lab 2 Cluster” throughout these instructions.

You will notice that there are several other resources located in this list. Grouped in the Cloud Foundry services, you will see resources like DroneLab_Secure Gateway-jv, DroneLab_API Connect-52, and DroneLab_App Connect-68. These will be utilized in later steps throughout this lab.

Cluster B will be used in this lab to demonstrate how services and applications located in a public cloud can communicate with services and applications in a private cloud. For this lab, imagine that Cluster B is private, and you want your application to have the ability to communicate with services located in this separate Cluster B. You will see in later steps why this is, based on the services located in this cluster.

1.3 Open RedHat OpenShift web console

Let’s examine this cluster’s (droneLabs) overview of the resource.

You will remember from Drone Lab 1 that on the left side is the additional settings menu. In the middle is the summary card for the cluster. On the right side, you’ll see worker nodes/cluster insights. It includes diagnostics and status information about the cluster. All of this provides a summary of the OpenShift instance before you jump in and work directly inside of it.

Click on the OpenShift web console button in the top right to access the console.

When you click this button, you may be prompted with an alert saying you need to enable pop-ups. If you get that prompt, enable pop-ups for this site click the OpenShift web console button a second time and wait for the new page to open.

It may take several seconds for this new tab to load completely. The reason for this is that you have moved into a RedHat OpenShift instance. Here you can see which projects and applications are deployed on your cluster.

You should see the drone-controller node already located in the topology. As mentioned earlier, imagine this cluster you’re currently in, Cluster B, is GSC-To-Go’s private cluster, where their own applications and services are located. Your Remote Drone Operations Console application, on the totally separate and public Cluster A, wants to communicate and use these services, but the organization wants to make sure this is done properly and securely.

You will recall that your Remote Drone Operations Console had a component to “Connect” to some available drones.  In the next several steps, you will learn how this connection can be enabled, starting with the use of Secure Gateway.

1.4 Setting up the Access Control List (ACL)

In the introduction of this step, you read an analogy made regarding the Secure Gateway Client, acting as an on-prem bouncer, checking who wants access based on their list. This list is significant – it’s referred to as the Access Control List (ACL). You can allow or restrict (deny) access to on-premises resources by making modifications to the ACL. This can be done interactively using the client commands or specifying a file that contains the ACLs you want to have in affect.

ACL enables the Secure Gateway client to access the identified resource (hostname or IP address) in the environment and allows the request from Secure Gateway server. In order to identify the lab drone controller's information, click on the big center icon for the drone-controller node, opening the right side menu.

This right side menu lists all the details for the drone-controller node. You will notice that the pod is running, builds, services, and routes. For now, let’s take a look at the service resource,  where you can get the drone-controller's route name (hostname) and port#, which has the S icon before it.

Clicking on the drone-controller services opens a full page view, complete with all of its related service details. Take note of the Service Routing on the right side – you will see the Cluster IP address location, along with Service Port Mapping (8080). To make it easier for lab administration, for the next steps you will use the namespace instead of the Cluster IP address. It should be noted that both will work and enable access accordingly.

Under Service Overview, notice the Labels section. One label starts with “route-name=”. The route-name is what you will use for the Access Control List. For your convenience, your route name was generated below for easy access.

What you copied here will be used more than once in this lab. It will be provided to you again in later steps.

When you were provisioned this lab, you were placed in a project group based on the availability of connected secure gateway client connections and destinations at the time based on the associated pricing plan options. our assigned Secure Gateway group number was provided as part of you customized instructions link, which you can view below.

The Secure Gateway Client group number you were assigned is important in navigation to the next project will access. Let’s go to it now by leaving the Service Details page and heading back to the Topology view.

Click on the Project dropdown to select the project where your Secure Gateway Client resides. Keep in mind that this will be different for various lab users depending on the group number you were assigned to in Step 1.4.3. In this example, the instructions lab user was assigned to group #1, so the project they chose was secure-gateway-client1. It is critical that you select the secure-gateway-client project that contains the group # you were assigned – otherwise, you will encounter errors. As a reminder, your Secure Gateway number is ___. (If it says you are unassigned, please send an email to gscgov@us.ibm.com, which you can click in the top right, along with the message, “I do not have a Secure Gateway number assigned”.

Make sure you are in the Topology view. Once you’ve selected your matching project, you’ll notice that a node has already been deployed within this Secure Gateway Client project. Once you click on the node’s Open URL button, located in the top right of it, it will open the route endpoint which contains a friendly user interface for updating the ACL. Click on the Open URL icon (top right corner of the node, see screenshot as reference) to open the endpoint.

What you’ve opened in the previous sub-step was the Secure Gateway Client – the bouncer, so to speak. It contains the ability to View Logs, see Connection Info, and most importantly, have a designated Access Control List. Let’s take a look at this list and add the address you copied in Step 1.4.2.

What you’ve opened in the previous sub-step was the Secure Gateway Client – the bouncer, so to speak. It contains the ability to View Logs, see Connection Info, and most importantly, have a designated Access Control List. Let’s take a look at this list and add the address you copied in Step 1.4.2.

Your route name drone-controller.YourLabName-2020-lab-2.svc.cluster.local Copy to clipboard 8080 is the port. Paste your route-name address from Step 1.4.2 into the “Resource Hostname” field under Allow access. Type 8080 into the “Port” field. Then click on the Plus (+) button to add it. Congratulations! You added your drone-controller route name address to a list of allowed hostnames, which is managed by the Secure Gateway Client. In the next step, you will finally add a destination, which will define how to connect to the resource.

Step 2: Use API Connect to manage and expose a service’s APIs

In the previous step, you enabled access to a private resource using Secure Gateway. Of course, connecting to a service involves much more than just enabling access. There are many actions you may want to perform in order to interact with the service as well – these actions and events must be understood by the service and your application.

Think about a time you clicked “Checkout and Pay” on an online store or hit “Confirm Appointment” on a clinic’s website. It happens so quickly and seamlessly, and with just a few taps and clicks, disparate services are able to talk to one another so you can quickly get what you need. An API, or Application Programming Interface, is the messenger that takes requests and tells a system what you want to do and then returns the response back to you.

To make it easier, imagine you’re in your car at a drive-through fast food restaurant. When it’s your turn, you tell your order through the microphone or directly to the employee at the window. Your order is made inside, you pay, and your order is handed over to you. In this instance, the fast food restaurant’s kitchen staff are ready to cook - but they need some way of getting the orders to them. The employee at the window provides that link of communication - when you say “#3 with no onions”, the employee at the window understands, and the kitchen staff understand exactly what that means, and make the order. You know this worked by getting your result - a bag with “#3 with no onions” in it.

Imagine how chaotic and disorderly it would be if everyone in the drive-through had to tell their order to kitchen staff directly. Thankfully, the employee at the window takes orders in a way that everyone can understand - you in your car, and the kitchen staff. The kitchen staff aren’t overwhelmed by taking orders from unfamiliar people, and the people in the drive-through can relax and not have to deal with communicating with the kitchen staff – they all end up talking to the one employee at the window.

That employee at the window acts as the API, or the messenger, and the kitchen staff acts as a service you want something from.

Now imagine if you owned a kitchen, or multiple kitchens all cooking different things – you would definitely need even more employees at the windows! How would you manage all of them? Is there an easier way to deal with order-taking employees that would work best for you? That’s where a service like API Connect comes in - it allows you to quickly create endpoints that can act as APIs and microservices, which are ready to be leveraged by other applications/services. You can also manage your APIs by setting varying levels of security and visibility, including rate limits. IBM API Connect is an integrated API management offering that allows developers to create, run, manage and secure APIs. The API Connect service also lets you transform and grow your business with insights through detailed analytics with structured filtered searches. In Step 2, you will specifically use API Connect to expose a set of APIs from that service you exposed using Secure Gateway (Step 1).

Recall a similar diagram in the beginning of the previous step. As mentioned before, this diagram will grow as you complete each step – notice how this step has added to the different ways your Remote Operations Console communicates with added services.

2.1 Add a catalog

In the first step, other services under the Resource List were shown but not delved into – including API Connect. This service exists already in the 1500867 – IBM account. Let’s start by navigating to the API Connect service.

The API Connect dashboard may contain a few catalogs that already exist. Before you go any further, let’s take some time and learn what exactly catalogs are with regard to API Connect.

Start by clicking the Add button in the top left corner and selecting “Catalog” from the dropdown menu. This will show a pop-up which will prompt you to provide a name. Your catalog name will be YourLabName-catalog.

Click the “Add” button in the top left corner, and select “Catalog” from the dropdown menu.

Change the Display Name * to YourLabName-catalog, then click Add. (This may take a few moments).

You should see your newly created catalog now along with the others that already existed in the API Connect dashboard. Take a look at what the catalog provides out of the box before we begin adding to it.

Along the top of this catalog are various options you can drill-down into – Products, Approvals, Community, Members, Analytics, and Settings. For now, let’s focus on getting ready for the next sub-step of importing API definitions. Click on the >> button in the top left corner, next to the home icon. This will open a side menu on the left side that contains Favorites, Dashboard, Drafts, and Admin. Let’s move to the Drafts.

Within the Drafts page, you may notice other products or API drafts which have not yet been deployed to a catalog. There are two options at the top – Products and APIs. When we import an API definitions file at the next sub-step, you will also be able to add a product at the same time. Click on APIs at the top to get ready for Step 2.2. To make it easier for this lab, we have already created an OpenAPI definition to get a drone's telemetry data that you can import into API Connect and modify. In the real-world, developers will create the API definitions using API Connect's easy-to build API Connect designer feature and distribute it.

2.2 Work with OpenAPI definitions

In the previous sub-step, you navigated to the Drafts page in your new catalog, and left off at the APIs tab. It’s time to finally add a product with some API definitions to this catalog.

Within API Connect, you can use an OpenAPI definition file to add a REST API. OpenAPI defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.

For your convenience, we have already provided an easy-to-use OpenAPI Swagger YAML file URL. The link provided is custom to you – your lab name – and will provide all the definitions required for setting up the APIs for this catalog. There are fields available for Username/Password authentication should your URL require it, but the URL provided to you does not require this authentication, so leave it blank.

Once you have pasted your API Connect YAML file URL, go ahead and check “Add a product” - new fields will show below. For this lab, as you import this  API definition, you also want to create a new product for the API.

If someone already had an existing product,  they could simply import the API definition and choose to add it to a product later. Importing API definitions will allow you to also add a product along with it at the same time. Make sure your information is similar to the below images – under Info, the title of your product should be yourLabName-product. And under Publishing, make sure “Publish this product to a catalog” is checked and then select your newly formed catalog, yourLabName-catalog, from the list. Once these details are added, click “Import”. It’s important to note that APIs become accessible to other application only when a product is published in a catalog.

After clicking Import and entering the correct details above, your page will update and look similar to the image below. You are now in the Design view of the APIs – and thanks to the work you did just now, you were able to import the API into a new product, and associate it with your catalog.  In the next sub-step, you will explore this page a bit more and make a few changes as well.

2.3 Edit and publish API product

In this Design view, you have access to a working draft of the API you imported. There’s a side menu on the left which contains headings for all of the sections related to this API. Indeed, this entire YAML-style page scrolls and is split up by these sections. Feel free to pause these instructions and scroll up and down this Design view.

Some sections to pay attention to include the first one at the top –like Info which contains the foundational details related to this API. Scrolling a little further down, the section Scheme designates the HTTPS configuration this API uses.

Looking over the Parameters section will be useful in Step 2.4 when you test the API itself – pay attention to the two user-defined parameters, drone_id and time_stamp, which provide drone identifier and time stamp to fetch the associated drone information.

The Path section is where the endpoint path is defined – currently it’s just GET /status. When you imported the API definitions in the previous sub-step, those definitions were already created for you based on your customized YAML file.

Let’s move on by setting the path of the target endpoint of the exposed drone controller application that we enabled with Secure Gateway in Step 1. Scroll to or click the Properties heading on the side menu.

Once you’re selected the Properties section, find and click on the selected API property – target_host, a user-defined property where connection information will be provided to reach the necessary target resource. Clicking target_host will expand to show catalog-specific values for this property that you’ll need to edit.

Take a closer look at this target_host property. As its description suggests, this property specifies the host for the target URL. Remember at the end of Step 1, you pasted the Cloud Host : Port into these instructions for future usage. Later on, the target_host value for this API is manipulated based on the value it has been provided. Let’s replace this current value with your Cloud Host, conveniently provided below.

Now that you have made that change, click on the Save button (floppy disk icon) in the top right corner. You should see a quick alert in the top right informing you that your API is now saved.

Making changes to the API requires republishing the API product. Navigate away from the Design view to the Assemble view – located in the Assemble tab along the top of the page.

This Assemble view provides tooling for simple to complex flows that can be tested. You’ll notice there’s already a default action pre-configured (invoke). We won’t be changing anything here as this lab doesn’t involve further configuration of flows within API Connect. You need to republish the changes you previously made. Click on the Play button ▶ near the top to change the side menu. Click on the Play button ▶ near the top to change the side menu.

The side menu on the left updates with new options regarding setup – you can double-check to make sure the correct catalog and product is selected before you republish. Once you’re ready, click Republish product so that your earlier changes are ready to go. It may take a few seconds for it to finish. In the next step, you will finally get to test out this new API and view its data response.

2.4 Explore and test API

At this point you have successfully created a catalog, imported and edited an API within a new product,  and republished it to your catalog.  The API is now ready to be tested. Recall in the introduction of this step – APIs act as messengers between applications and services. In the previous sub-step, you saw the GET /status endpoint – it required two values (drone_id and time_stamp). When you make a request to get information about a specific drone at a specific time, you will get back a response that includes information in a format that is understood.

Let’s begin trying out the API by clicking the Explore button in the top right corner. This will open a list where you can select your own catalog, yourLabName-catalog.

The Explore tool is used to test API endpoints. It shows the operations for all of the APIs that are contained in a specified catalog. The left pane of the Explore window can be used to select an operation to test. The center pane displays summary information about the endpoint, including its parameters, model instance data, and response codes, and the right pane provides template code to call the endpoint. Let’s focus on the right pane for now. Notice the URL at the top preceded by GET, and the curl request. Click on “Try it” to start testing yourself.

Finish Step 2

You successfully used API Connect to expose APIs in the GSC Drones-To-Go service by creating a catalog, importing a YAML file with API definitions, made changes, republished, and tested out the API within the API Connect Explore tool.

In the next step, you will use another service to demonstrate the value of invoking flows involving other services.

Step 3: Connect to another service with App Connect

Imagine you’re in charge of running a small event online at your workplace. Whenever someone registers for the event, you want them to receive a (1) confirmation email, (2) Slack message telling them where they can connect with others about the event, and (3) store their registration information in an Excel sheet. This could be all done manually – but obviously, you’re a busy person, and you may only get time sparingly to do this, and it is still prone to human error. It may get overwhelming if a lot of people sign up at the same time. You may also think – aren’t there services that can do this automatically for me?

In Step 2, you imported API definitions that were able to be tested within API Connect. You were able to view that response data that the API produced – data that could be part of a bigger flow of events. For the event example above, you could use the registration data and have a template for an email ready to go. The registration data could also be used to automatically send a pre-defined Slack message to the signed-up person, and automatically add a row of information to an Excel sheet.

IBM® App Connect connects all these applications very quickly, regardless of whether they are on the cloud or a private network. And significantly, there is no coding required. Using the App Connect Designer on IBM Cloud makes it easy to connect apps, even applications like Salesforce, Marketo, and SAP, so that when an event occurs in one application, or a request is made to an API, the other connected apps are updated automatically.

Below are some common templates used on App Connect. These contain prebuilt flows which can be created for an API, so that when the request is submitted (such as through a mobile or web application), the flow performs all its actions, and then returns a response that either confirms that the actions were successful, or returns the data that was requested.

The lab diagram that has been referenced before is finally complete – take a look below and notice how each step was able to add onto the connections that your Remote Operations Console application had access to. With each service, your application became more powerful due to it being linked to useful resources. As it suggests, you will use the response data you previewed in Step 2, which included the location of the drone, to retrieve data from a database of sensors, thereby creating a very helpful list of sensors near the drone.

3.1 Explore sensor database

Before you access the App Connect service, let’s take a look at the database of sensors. In real-life situations, a Public Safety Situational Awareness Operator may want to quickly look at the nearby sensors to gauge the condition of the location they are viewing through the drone. It’s convenient that the GET /status API provided in Step 2 contains the latitude and longitude of the done location that can be used with the sensor location coordinates as well.

The sensors’ information is stored in a Cloudant database. IBM Cloudant® is a fully managed, distributed database and is provided as an offering on IBM Cloud. It has already added to your IBM Cloud account. Once you click on the service, launch the dashboard to view the databases. You will take a look at the databased named sensordb.

Once you click the sensordb database, a list of sensor information will be displayed.

One of the many features Cloudant provides is IBM Cloud Geospatial, or "IBM Cloudant Geo”. Cloudant Geo combines the advanced geospatial queries of a Geographic Information System (GIS) with the flexibility and adaptability of IBM Cloudant's database-as-a-service (DBaaS) capabilities. These capabilities include GeoJSON, IBM Cloudant Geo index, and more.

With IBM Cloudant Geo, all of the following are possible:

(1) Enable web and mobile developers to enhance their applications by using geospatial operations that go beyond simple bounding boxes
(2) Integrate with existing GIS applications, so that they can scale to accommodate different data sizes, concurrent users, and multiple locations.
(3) Provide a NoSQL capability for GIS applications, so that large streams of data can be acquired from devices, sensors, and satellites. This data can then be stored, processed, and syndicated across other web applications.

Let’s take advantage of this feature. Sensors have locations that be filtered on – within Cloudant, you’re able to draw polygons on a map and define spatially which sensors to display in a given bounded area. Go ahead and draw a circle on the map to filter sensors.

The circle you drew has filtered the sensors to only return the ones that are located within the boundary. When you click the JSON view, the list of JSON data pertains to the sensor markers shown on the Map view.  While the details returned  at this point is limited to the identifier and coordinates for each individual sensor, this information could then be used to query the type and values for each sensor which is useful in later lab sub-steps.

In the next sub-steps, you will use the location data you were able to return in the end of Step 2 in combination with the information located in the sensors in this database to return a list of sensors nearby.

3.2 Set up App Connect flow

Now that you have a preview of what the sensor database and its information looks like, let’s set up the flow. Close the two tabs you just opened related to the sensor database, and open the App Connect service in your IBM Cloud Resources. Then, click Launch App Connect to begin.

This is the App Connect Home. You may notice that there may been integrations that have already been created – these artifacts reflect connections that other users have made. This dashboard also provides an overview of available functions that App Connect provides.

Let’s start by clicking on the Dashboard icon (you may need to hover to view it) on the black left side menu. In order to add a new flow, you will import its definitions that have been provided for you (similar to Step 2). On the top right corner, click New and then Import flow.

Using the copy to clipboard button, copy your YAML file URL below and paste it into the pop-up’s, “or specify a file URL” field. When you click Add file, it will import the YAML file containing your lab name. Click import to complete the process.

Once the flow has been added (this may take a few seconds), the screen will update with Define view for the flow you created. Remember these two functions – retrieveSensordata and getNearBySensors. You will focus on getNearBySensors for the purposes of activities in the next several steps, but you will also be exposed to retrieveSensordata and asked to consider it within the context of the lab’s Production Flow used by the Remote Drone Console application.

Take a look at the various Properties associated with the getNearBySensors – droneid, lat, lon, radius, and response. You will provide a droneid, the latitude and longitude coordinates from the drone, and the radius you are interested in, and get a response. Notice that these properties are strings as well.

You may have noticed that retrieveSensordata has fewer Properties – only droneid and response. This will be explained as you continue through this lab section.

The getNearBySensors API is a simple API flow to demonstrate the capability and simplicity of the App Connect cloud service. For the lab, we developed this flow to show how a web application could get access to Cloudant sensor data that is in close proximity to a given drone’s location by providing the lat/long as input.

The retrieveSensordata may be more typical of a production API flow in that it combines several steps and includes some additional logic. Specifically, this flow is different from the simplified getNearBySensors API flow as it retrieves the drone’s status and telemetry data using the drone controller’s GET/status API (from API Connect), parses the response to find the drone's location (latitude/longitude) information, and then uses those locations details as input to retrieve sensor readings from the Cloudant database that are in the relevant area. This flow is used by the Remote Drone Console application as part of the lab’s Production Flow.

App Connect provides a model-driven, code-free approach that lets you easily implement your API operations as integration flows. For less experienced users, App Connect guides you through making models and integration flows you can use to build robust APIs. For experienced developers, App Connect's powerful tooling lets you extend the flow through code. In either model, the tool then builds well-formed OpenAPI definitions automatically. 

You can preview the flow within App Connect for getNearBySensors by clicking on the Operations tab on the section and then Edit flow (this may appear as "View Flow". The flow you see is linear – Request > HTTP Invoke method > JSON Parse > Response. As you continue to finish this lab, consider how this flow could be used within the Remote Console Operations application.

You can see that a simple linear visual flow represents the step by step actions that happen within the getNearBySensors API. If you click on each step in the visual flow, you will see the details reflected underneath. For example, the output below shows the details of the HTTP step.

3.3 Start the API

Now that you have set up the flow in App Connect, let’s test it out – but first, you’ll need to start the API and change authentication settings.  Begin by moving to the Manage view.

If you are unable to see or view the Manage tab, refresh the page. You may need to change browsers if this does not work.

Once you’re in the Manage view, you’ll be able to view and change settings related to the API flow.

Scroll down to the Security and Rate Limiting section. Pay attention to the section names as some are named similarly. For this lab, you will turn off “Require application via API key”. This lab does not include viewing the usage of the APIs so this authentication isn’t required. It should be noted that for production level implementations, it may be appropriate to require authentication so that applications that use this API would need to authenticate using an API key and secret or API key alone.   This section would thus manage its key sharing and provide visibility into the API usage after the API is online. Make sure you scroll down and save this change once it is turned off.

A pop-up at the top right corner will confirm your changes are saved.

Once this change has been saved, click on the vertical 3 dots at the top next to “Stopped”. Clicking Start API will make this flow active. By making this API active, applications will now be able to use the functions that were shown in the previous sub-step. Click on the 3 vertical dots next to Stopped in the top right corner. Then click Start API.

In the Sharing outside of Cloud Foundry organization, you’ll notice the description: To share the API with a developer who is not a member of your Cloud Foundry organization, first create an API key and a companion API documentation link. Then send the key and the link to the developer, who can then use the corresponding page to explore the API and create an API secret (if required).

If the above “Require authentication via API key” was enabled, you would first need to create an API key in order to use the API Documentation link.  Because this isn’t required for this lab, all that is needed is to use the API Documentation Link (from screenshot below) for the remaining substeps.

3.4 Try out the flow

Under the Query section, notice the API input parameters lat, lon, and radius. You’ll enter the location values that you should have gotten back at the end of Step 2 from the drone #1 you specified. Enter the following values in the corresponding fields and click Send to send the request. Scroll down after to view its response.

You should see a sensor reading response below that starts with a 200 OK Response. Congratulations! You were able to test the simplified getNearBySensors flow that you added within App Connect. If you look closely at the JSON results contained in the response, you may notice the type of sensor and current values for this particular device.

Thinking about our Remote Operations Console application, you can consider how App Connect’s flow can expose a single API (via the  /retrieveSensordata Production flow) that retrieves and parses a drone's current location, and then goes on to query the sensors in that immediate geospatial area to bring the values to the user. In the next step, you will visit and review the Remote Operations Console application's updated user interface and consider how these service connections enabled the Multi-Hybrid Cloud application with powerful functionality.

In the next step, you will visit and review the Remote Operations Console application's updated user interface to understand how these service connections  enable that Multi-Hybrid Cloud application with powerful functionality.

Finish Step 3

You successfully used App Connect to add a flow that can take drone location information and find nearby sensors in a given radius.

In the next step, you will revisit the Remote Operations Console application and take a look at the Drone Viewer which incorporates some the services you delved into in previous steps.

Step 4: Explore Remote Operations Console with new flows

In the Steps 1, 2, and 3, you learned about the three main services that were integrated with your Remote Operations Console application. These three services are Secure Gateway, API Connect, and App Connect. Let’s review each briefly:

Secure Gateway A cloud service that enables you to establish a secure tunnel between the specific resources you want to connect. Used to enable access to GSC Drones-To-Go, a private cloud service.

API Connect A modern, intuitive and scalable API platform that lets you create, securely expose, manage and monetize APIs across clouds. Used to create and add APIs that can request and respond with data that belongs of the GSC Drones-To-Go drones.

App Connect An all-in-one tool for easily connecting apps, integrating data, building APIs and acting on events. Used to invoke flows that can retrieve nearby sensors based on location data of a drone.

Over the course of this lab, you viewed a diagram that showed how the Remote Operations Console application connected with these services. It is complete – review it once more before moving on.

Your Remote Operations Console application is connected to the private cloud that hosts the fictional company GSC-Drones-To-Go service, which is hosted in the IBM Industry Engineering Lab in Coppell, TX.

You may remember that in Drone Lab 1, you saw a list of drones but didn’t go much further than that. In this lab, you will finally get to view what the drone sees, view telemetry data it provides, and see its relevant geospatial information.

If you want to recall specific information regarding the Remote Operations Console, it is recommended you read the instructions for Drone Lab 1, located here: https://ielgov.github.io/dronelab1.

There are two steps worth reviewing prior to finishing this lab.

Step 2 of the first lab contains information regarding accessing RedHat OpenShift through IBM Cloud. While this lab has primarily used Cluster B, you will be revisiting the Cluster A you used in Drone Lab 1. If it’s been a while since you have completed the first lab, it is recommended that you look over this step, including the components related to the OpenShift web console, which will not be covered in detail in this second lab.

Step 5, you may recall, of the first lab contains a breakdown of specific parts of the console application UI. This step contains clickable sections of the page that go into detail regarding the function of each widget. This second lab will not cover this content again and will go directly to a new section of the console application UI - so if it’s been a while, it is recommended that you go over this step again.

4.1 View configurations made for this lab

Now that you’ve explored the services that were used in the Remote Operations Console application, let’s revisit the application and how they were used. As mentioned in the introduction, reviewing certain instructions in Drone Lab 1 may be helpful.

Navigate back to Cluster A, or mycluster-dal12-b3c.4x16, which is a part of the Resources in IBM Cloud. This should be familiar from Drone Lab 1 – launching the OpenShift web console will allow you to choose the Developer perspective, enter the Topology view, and select your project. It is critical you follow those steps correctly – not doing any of them will result in errors.

Once you have completed the 3 steps above, your Topology view may be similar to what you see below. It is okay if your Topology is different – you will review the nodes in this view in the next sub-step.

4.2 View configurations made for this lab

In the Topology view, you may see a number of nodes that already exist – some of which are remnants of Drone Lab 1. Review the list below.

Before you revisit the Remote Operations Console application, let’s take a quick look at some of the configurations that were made in Drone Lab 2.

Notice the environment (env) variables in the Environment tab for this HTTP forward node. Just as you explored Secure Gateway (SG), API Connect (API), and App Connect (APP), there are values that have already been provided that are similar in syntax to the URLs you had produced in each previous step. Since the Remote Operations Console application has already been connected to the GSC Drones-To-Go service, these values were already taken care of for you.

4.3 Explore the drone viewer modal

Let’s revisit the Remote Console Operations application. Using the endpoint associated with the lab2-dronelab-ui node, click on the top right Open URL icon of the node to launch the site.

Click on the Open URL button in the top right corner of the lab2-dronelab-ui node.

This website should be familiar from Drone Lab 1 - if you would like to review each section of the Remote Operations Console, please revisit Step 5 of the Drone Lab 1 instructions site https://ielgov.github.io/dronelab1. When you’re ready, go to the Available Drones section. Notice that the list of drones each have a status. The drones with the Available status can be connected to. These are the drones provided by the GSC Drones-To-Go service, and thanks to the services you explored earlier, this application is able to get access to these drones. Click on Connect on either of the drones to open its drone viewer modal.

The drone viewer modal may take a few seconds to fully load all of its components. When it’s finished, take a look below at the various parts it has and the descriptions for each. You will focus on the Location section next.

In the Location section, turn on the Sensors in the map layers. You’ll notice that there a few sensors that are near the drone itself – click on one of them to view its information. If you recall in in Step 1, you enabled access to these drones in the GSC Drones-To-Go private cloud service with Secure Gateway and in Step 2, you were able to get the drone’s location coordinates through an API you had set up, and all of the sensors could be filtered to show nearby ones using the flow you added in Step 3. The connections to these services can be observed as you look at this section.

This completes all the steps for Drone Lab 2 – congratulations! Close this modal and feel free to view the other drone you did not view to see its modal information as well.

Please take a screenshot of the drone you liked seeing more and post it in the Slack channel with your feedback on this lab. Then move onto the next section.

Finish Step 4

You successfully explored the topology view during and after the build process and checked the status to see your changes in the application. OpenShift took the Dockerfile from your GitHub repository and used its instructions to build the application image from the current repository code. You have utilized your skills to deploy an application on the latest multi-hybrid cloud platforms.

In the next step, you will explore your new custom remote drone dashboard application, along with various industry uses cases to consider.