#1077 OCI API Gateway & OIC

OCI API Gateway can be used to manage access to your your integration apis. This post goes into a bit more details on the mechanics of such, for different types of integrations.

The initial setup of the gateway is detailed here.

Now to my integrations - 

First HalloWelt - 

Let's expose HalloWelt via the gateway.

That's it - 

Pick up the endpoint, once created - 

Test from Postman -

Now to the next integration - 

This integration pushes a file to OIC file server.

Now to test this from Postman, firstly I take the curl representation of the request - 

and I drop it into Postman. I could also have copied the endpoint url from here -

 

That worked fine - let's look at the postman console - 

Note the Content-Type header.

Now I expose this via the api gateway. For this to work, I need to set the following in the route -

As you can see, I'm explicitly setting the headers. In fact, I'm passing on what I receive from postman. Note the syntax for referring to the Content-Type - ${request.headers[Content-Type]}.

I now run this from postman - 

Let's remove the Header transformation - 

 

I get the following error in postman -

Exception while processing Trigger request for </ic/api/integration/v2/flows/rest/project/AA_LARGEFILEPROCESS/WRITELARGEFILETO_V2/1.0/file>. Error Message : Unsupported media type in the request 


Let's include some more logic here - if the size of the file <= 1MB then route to integration A, else route to integration B. As you can see, I've added a new integration to my project.

I will cover 2 approaches here -

1. use of an X header
2. interrogate the Content-Length header. Here we need to interrogate the http header Content-Length. We could refer to this as ${request.headers[Content-Length]}.

Use of an X-Header

Mine is called X-Large-File, with 2 possible values, Y & N.

 

I create a new deployment and add the following rule to the route -

Test from postman, with the X-Large-File header set to N.

Now test with the header set to Y.

Checking the Content-Length value

Essentially we want to implement the following check - if content-length > 1MB then invoke the large file processing integration, else invoke the small file processing integration.

Net, net - ${request.headers[Content-Length]} > 1048576 (bytes).

Unfortunately, we cannot implement this directly in the api gateway. We need to implement a multi argument authorizer function, to take the value of content-length, cast it and perform the required comparison. Then we can set an auth context, such as backend = large_payload_service or small_payload_service. That auth context can then be used as the selector.

Here's the python code -

import io

import json

import logging

# comment

def handler(ctx, data: io.BytesIO = None):

    body = json.loads(data.getvalue())

    content_length_str = body.get('data', {}).get('Content-Length', '0')

    content_length = int(content_length_str)

   

    if content_length > 1 * 1024 * 1024:  # 100MB

        response =  {"active": True,

                     "context":

                      {

                        "backend": "large_payload_service"

                      }

                    }

    else:

        response =  {"active": True,

                     "context":

                      {

                        "backend": "small_payload_service"

                      }

                    }

    json_response = json.dumps(response)

    return json_response

       

Now that we have the function, let's use it!

 

 

#1076 OIC3 Service Metrics - Monitoring Concurrent Synchronous Requests

The sync request concurrency limit is based on the number of message packs you have assigned to your OIC instance.

1 pack = 100 concurrent sync requests
5 packs = 500 concurrent sync requests
10 packs = 1000 concurrent sync requests etc.

Net, net, you get 100 per pack assigned.

This service limit as well as the others are detailed here.

But how can we monitor this limit, e.g. see if we are in danger of hitting this?

OCI Service Metrics

Well try the following MQL from OCI Service Metrics for Integration -

NumberOfInboundRequests[1m]{resourceId = "<instance-id>"}.groupBy(serviceInstanceOcid).sum()/60 * InboundRequestProcessingTime[1m]{resourceId = "<instance-id>"}.groupBy(serviceInstanceOcid).mean()/1000

Here is a simple example in Service Metrics --> Metrics Explorer (Advanced Mode) -

I run some load tests and check the concurrency -

I check out the chart and see I'm up around the number 90.

Maybe a good idea to consider adding another message pack to this OIC instance.

OCI Alarms

Let's create an alarm, based on this metric -

We also need to amend the query, adding the condition, in my case, > 80.

NumberOfInboundRequests[1m]{resourceId = "<instance-id>"}.groupBy(serviceInstanceOcid).sum()/60 * InboundRequestProcessingTime[1m]{resourceId = "<instance-id>"}.groupBy(serviceInstanceOcid).mean()/1000 >80

Now to defining the alarm target, in my case, I want to send an email to myself.

I run a couple of more tests from SOAP UI, ensuring I exceed 80. I then check my email -

I also receive an email when the alarm is no longer firing -

OCI Logging Analytics

As you see, I've added a widget to monitor concurrent sync requests.

I'll now add another one, to provide a more visual rendering.

and click Run.

Now let's change the visuals - 

That looks better! Now edit the widget name etc. 

Save the widget - now it appears in your dashboard.

Summa Summarum

Now you easily monitor your concurrent synchronous request processing limit. 

You can view your instance limit in your OIC Observability Dashboard - 

I have covered 3 modes of monitoring in this post -

1. Metrics Explorer

2. Alarms

3. OCI Logging Analytics

I would strongly suggest a combination of options 2 & 3.