#1188 - Integration generation with Claude and Codex

 

Greetings from AI World@Las Vegas. Today's post looks at integration generation from Claude and Codex desktop on my laptop. All I need is to have my OIC designtime open in my chrome browser.

I then begin by opening Claude and asking it to create integrations etc. in OIC.

The agent, as you will see, does the magic. I start with a very simple HelloWorld style integration and then progress to something more complex.  

Please note, I have not provided Claude with any OIC specific skills; net, net, I'm leaving it up to the agent to figure out what to do.  

Claude - integration creation

I begin by asking Claude to create a new OIC project called Vegas. Initially, it doesn't work - I need to install Claude in Chrome. 

I install Claude in Chrome - 

I enter the request again and watch the magic happen - 

I created the Vegas project on your oic3dev-NNN (Dev) instance, with the identifier VEGAS. It's a blank project, and OIC opened straight into its detail page. The page is still open in my tab in Chrome if you want to start adding integrations or connections.

I enter the following - 

Please add a REST connection to the project. It should be of type trigger, using OAuth2 for security. Call it simply REST-Trigger

I open the project in a separate browser tab -

Note, it's locked.

Create HelloWorld

Back in Claude - Create a simple HelloWorld integration, using the REST connection. The business logic is simple - append 'Hello ' to the name entered in the request 

I add the concat manually then ask Claude to continue - 

It responded - 

The mapping looks right: concat("Hello ", …/QueryParameters/name) → message. Validating and saving now.

Validated. Going back to the canvas to save.

Saved. Now activating it from the project page.

No Activate option, and it's still Draft, so something is flagged. Checking the error badge in the editor.

It's missing a primary business identifier. I'll set the name parameter as the tracking field.

That drag worked. Saving.

Now Configured. Back to the project to activate.

HelloWorld is built and active on your oic3dev-core-oicpm-px (Dev) instance. OIC reported "HelloWorld activation succeeded".

The integration has three parts:

• Trigger: the REST-Trigger connection, GET /hello with a name query parameter. It uses OAuth 2.0 security, inherited from the connection.
• Map: message = concat("Hello ", name). The map passed validation.
• Response: JSON, so ?name=Niall should return {"message":"Hello Niall"}. I haven't called the endpoint to confirm this.

Activation was blocked at first because OIC requires a primary business identifier. I set the name query parameter as the tracking field (tracking_var_1). Each run's instance will be tagged with the name passed in. I activated it with Production tracing, the default.

I couldn't use OIC's built-in test run because the Chrome window my tab is in is too short for its panels.

I do CTRL - twice in the browser window used by Chrome and then asked it to continue with activation / test.

Ok, there was some interaction required, but that is to be expected as I had no dedicated skills defined for this activity. However, the main issue was browser tab sizing, which caused the mapping issue. I will correct this later.

Create GoodbyeWorld

I now ask Claude to generate a similar integration GoodbyeWorld - 

No interaction required. Claude is cute enough to clone the existing HelloWorld integration.

Now to a new use case, with a bit more meat to it - 

create a net new integration, i.e. don't use clone. Title this integration - ProcessOrder and use the following payload - {"orderNr":"123",

"customer":"NiallC",

"customerCountry":"Ireland",

"product": "iBike",

"price": 3999,

"orderStatus":"new"}

The processing is simple, just add a WAIT action and set it to 10 seconds. Then add a LOGGER action to log the incoming customer and product. Return the same payload excepting the orderStatus value, set this to processed.   

Let's ask Claude to close the project - 

I open the project in a separate tab, just to see what Claude has created - 

Implementing a File based integration

Let's take this to the next level. The integration logic is simple - push an order to a file on OIC File Server. For this we will need a new folder - /ClaudeOrders.

I will request this to be created under /home/users/niall.commiskey@oracle.com

Now to permissions - 

I then ask Claude to edit the order processing integration and amend it to write the order to file server - 

It's response - 

ProcessOrder now writes each order to the File Server. A test run created order_123.json (0.12 KB) in /home/users/niall.commiskey@oracle.com/ClaudeOrders at 22:38:44.

Instance ID	Integration	Outcome	Start	End
bZChOdC8EfGkrRUbYvb5zA	PROCESSORDER 1.0.0	Completed (200 OK)	22:38:33.410 CET	22:38:44.442 CET

The flow is now: Trigger → Wait (10 s) → Logger → Map → File Server “WriteOrderFile” → Map → reply. The activity stream shows the WriteOrderFile invoke taking about 0.6 s.

How the new step is configured:

• It uses the native File Server action, set to File, Write File, with the output directory set to ClaudeOrders.
• The file name is order_<orderNr>.json, so each order gets its own file. A repeat orderNr would overwrite the earlier file.
• The File Server action only accepts a file reference as content. The mapping builds the order as a JSON string with concat, then converts it using oraext:encodeBase64 and oraext:decodeBase64ToReference.

I check the File Server folder - 

Note the power here; Claude worked out how to map the file reference from source to target.

Here's the integration design - 

I ask Claude to create a new folder, ClaudeOutOrders.

Create an MFT style scheduled integration

The next request to Claude is to create a scheduled integration that reads files from ClaudeOrders and writes them to ClaudeOutOrders.

create a new scheduled integration that reads files from ClaudeOrders. The integrations needs to loop over the files and, for each file, write it to ClaudeOutOrders. Delete the file from ClaudeOrders, after it has been successfully written. The schedule needs to be set to run on an hourly basis.

Claude asks me to set the repeating element, as it has issues with drag and drop, so I do as asked. 

I do as requested and drag startTime to the business identifiers section.

Claude also notes the following - 

This is excellent!

Here's the generated integration - 

Claude - Summa Summarum

Claude's ability to create integrations is very powerful. As we have seen, the only caveat is the support for drag and drop.

Also worth noting is how the agent goes above and beyond exactly what has been requested, delivering some best practices heuristics.

Regarding the drag and drop issue, Claude offers the following solutions -

Doing the same in Codex

The base project has been created. Now to creating the REST connection etc.

Now to creating HelloWorld -

Create a simple HelloWorld integration, using the REST connection. The business logic is simple - append 'Hello ' to the name entered in the request 

Codex also has issues with the Business Identifier drag & drop.

I do the necessary -

I ask codex to activate the integration and do a a sanity test.

Let's ask Codex to generate a similar integration, GoodbyeWorld - 

Tell it to activate and run.

Let's ask Codex to edit the integration and add a Logger action to log the name value.

I won't go any further with Codex; net, net, it's the same modus operandi, same excellent results.

Summa Summarum

Generating integrations from Claude & Codex is simple, you've seen for yourself here. However, it is definitely not the most token friendly approach. Try out computer use yourself and you will see the trial and error approach that is sometimes taken. Granted, the results are still impressive. I consulted Claude - 

Each full screenshot of that OIC window costs roughly a thousand input tokens. Building ProcessOrder alone took dozens of them, and across the whole session it ran into the hundreds. Most of those calls went on navigation rather than real work: opening menus, waiting out spinners, checking a click landed, retrying drags, and recovering from the lock and the disconnect. One logical change, such as “set orderStatus to processed”, took five to ten round trips. 

Imagine an MCP server approach here, providing access to the underlying OIC designtime apis. This could result in simply one call per operation and compact, json based, responses. It would also be deterministic, which is definitely what's required here. 

Watch this space for more info on such!