OCI API Gateway includes native support for publishing OCI Functions, this was especially useful for me as I wanted to make my function available externally without authentication – whilst it’s possible to make an OCI Function available externally without using API Gateway, it’s not possible to make a function callable without authentication (e.g. make it available to anybody on the internet) 🔓.

I’d ran through the process of publishing an OCI Function through OCI API Gateway a couple of months ago and got it to work successfully without too much pain, earlier this week I had to do this again and ran into a few issues – I was clearly a lot brighter back then! I thought I’d capture these issues and solutions to help others and for my future self 😀.

A step-by-step guide for publishing an OCI Function through OCI API Gateway can be found here – if only I’d have read the documentation, I could have saved an hour of my life. Below are the issues I ran into and the solutions that I found ✅

❌ Issue 1 – Calls to the Function timeout ⏱️

Using Curl to call the API Gateway endpoint for the Function timed out with the following error:

curl: (28) Failed to connect to bcmd2sv4corxwehdxx4lzvrj9u.apigateway.uk-london-1.oci.customer-oci.com port 443 after 75019 ms: Couldn’t connect to server

I’d provisioned a new API Gateway into a public VCN submit and had forgotten to permit inbound traffic on port 443 traffic to the subnet. To resolve this, I added an ingress rule to the security list associated with the subnet allowing traffic on port 443.

❌ Issue 2 – Calls to the function generate a 500 error

Once I’d enabled port 443 inbound to the VCN containing the API Gateway, I started to receive a different error when attempting to call the function using Curl (or a web browser for that matter):

“Internal Server Error”,”code”:500

To investigate this further I enabled Execution Logs for the API Gateway Deployment and sent some further requests, I could then see the following in the logs:

With the full error being:

“Error returned by FunctionsInvoke service (404, NotAuthorizedOrNotFound). Check the function exists and that the API gateway has been given permission to invoke the function.”

Damn…….I’d forgotten to give the API Gateway permission to call the Function, hence the not authorized error 🤦‍♂️.

To resolve this I created a dynamic group that contained the API Gateway – actually this contains all API Gateway’s within the specified compartment.

I then created a policy to permit this dynamic group (API-DG) access to call Functions – again this rule is quite broad as it provides the dynamic group the permissions to call all functions within the tenancy. Within a production environment, you’d be a little stricter here and restrict this to a specific Function 😀.

Issue 3 – I have no patience 😀

After working through issue 1 and 2 and resolving these issues, I was still running into problems – inspecting the logs yielded the same NotAuthorizedOrNotFound error. It turns out that I needed to wait for the policy I created to come to life, about 30 minutes or so later (during this time I was frantically troubleshooting!) it started to work and public calls to my function through the API Gateway started to work 👍.

Above is the output of my “workout generator” 🏋️ Function. If you’d like to learn more about creating a Function in OCI, check out – Creating a Function in the Oracle Cloud (OCI) to help me stay fit 🏃‍♂️