#1077 OCI API Gateway & OIC - Multiple Backend support

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 main example covers routing to different integrations, based on Content-Length. The use case is that of processing a file; files over 5MB are classed as large files, those <= 5MB are classed as small files.

I begin with a simple German version of Hello World, to get us started.

The initial setup of the OCI Gateway is simple. For those who want a step by step, check out my post 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 <= 5 MB 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 > 5 MB then invoke the large file processing integration, else invoke the small file processing integration.

Net, net - ${request.headers[Content-Length]} > 5242880 (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 > 5 * 1024 * 1024:  # 5MB

        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!

Some things to note

OCI API Gateway has a limit of 20MB on request body size.

Ensure the name you use as the argument in the Authorization call is matched in the python code - 

This is used in python - 

content_length_str = body.get('data', {}).get('Content-Length', '0')
 
The first execution of the function includes ramp up time, so expect this first invoke to take a little longer.

Log files for OCI API Gateway and Functions 

It's a good idea to enable logs, let's start with our deployment in OCI API Gateway -

As you can see, 2 logs - access and execution.

Testing

Small file test:

Large file test:

Viewing the Logs

OCI API Gateway, execution log - 

Functions Log - 

 

 

 

 

#999 23.12 - Publishing OIC endpoints to OCI API Gateway in detail

Welcome to this post, which will look at the publishing of OIC endpoints to OCI API Gateway.

I'm starting from scratch, with a new OIC3 instance -

This functionality is available only in domain enabled tenancies. I this demo, I will be provisioning the OCI API Gateway in the same compartment as OIC.

RPST is used for OIC to access api gateway, which is, in essence, just another Oracle Cloud Infrastructure resource. To this end, we will need the client id of the OIC instance I just created. 

So let's go to our domain - 

 

I save the Client ID for future use.

Create a Dynamic Group

Next step is to create a dynamic group, through which we will be able to grant gateway access to the api gateway. This group will only have 1 member to begin with, the OIC3 instance I just created. Naturally, I could have multiple entries i.e. many OIC3 instances publishing to the same gateway.

Here is my Dynamic Group definition - 

 - 

resource.id = 'client id'

Create a Policy

Now we need to create a policy which will enable this dynamic group to manage API Gateway in my compartment -

The Policy definition has the following format - 

allow dynamic-group yourGroup to manage api-gateway-family in compartment yourCompartment

Pre-requisites for Creating the API Gateway

Create a Virtual Cloud Network and Subnet

I create the VCN in my compartment NiallC-2312. As you can see, I set the CIDR Block value to 10.0.0.0/16

I accepted the defaults for all the other fields.

Create a Subnet

I set the CIDR Block to 10.0.0.0/24.

Subnet Type - Regional

Subnet Access : Public Subnet

Create an Internet Gateway

All you need here is a name.

Add Rules to the VCN Security List

Add the following Ingress rule - 

The following Egress rule should be present - 

Add a Route Rule to the VCN Route Table

Create a Network Security Group

That's it - pre-reqs completed!

Provision the OCI API Gateway

Give it a name and select the VCN and Subnet you just created. Accept defaults for the rest.

Create a test Deployment and route

This is a quick test to ensure our gateway is accessible. I create a deployment called Test and add a route. Note, I use a stock response here.

I will now test this from Postman - 

The deployment url can be found here - 

Publishing from OIC

Integrations need to be within a project, activated and also "public". 

For "public" just check the following box, when creating an integration -

There's our TestDeployment. In this case, I'll create a new deployment - Netsuite. Ergo, we can select an existing deployment or create a new one. Whichever we choose the OIC endpoint will be created as a route within that deployment.

I can, of course, view the deployment details -

Now to testing the invoke of the OIC endpoint via the api gateway. Again, I use Postman here.

First test is to invoke the OIC endpoint directly from Postman. This will leverage OAuth - the setup required is detailed in this other post

Looks good! Now to the route in the Netsuite deployment - 

The path, as you can see, is /netsuite/customer.

The Deployment url is - https://myGateway.apigateway.us-phoenix-1.oci.customer-oci.com/netsuite

So let's test this from Postman -