#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!

#1187 - Best practices for exposing integrations as tools

Introduction 

If you've been reading my blogs, even on an irregular basis, you will have seen how easy it is to expose existing integrations as agent tools.

One click exposure. One more click and you have exposed the project as an MCP server, thus giving 3rd parties access to the tools.

But is this the best approach? Will your integration developers be the ones exposing integrations as tools? Or could this be another group of users? 

Where different teams own integration development and agent tooling, separating these responsibilities provides clearer control.

In this post I give tool managers a controlled way to reuse integrations while integration owners retain control over what they share.

Controlled Exposure as Tools

I work on the basis that in many organizations, the person creating the integrations may not be the one exposing such as agentic tools. With that in mind, I create a new group in IDCS - OIC-Tools-Mgrs. I assign one user to this group; he is our tools manager.

As you can see, user Niall Mac Cumascaigh is assigned to the group. He also has the OIC ServiceDeveloper role, although he is not an integration developer. This role is required for him to be able to create tools in OIC.

Another user, niall.commiskey@oracle.com, has been involved in enterprise integration since his halcyon days of youth. It was he who created the project with these 3 integrations - 

This project is currently private, from an RBAC perspective - 

User Niall Mac Cumascaigh can see the project listed in OIC - 

but he cannot open it - 

The project owner can decide which integrations should be shareable; in our case, which integrations should be available as tool candidates.

Our veteran integration developer shares the get Invoice integration - 

Meanwhile, our tools manager creates a new tools project in OIC - 

This is where he will add tools - 

Now, our Invoices project owner applies RBAC - the view permission is required to use a shared asset. 

The OIC Tools Mgr can now create a tool based on the shared integration - 

He enters the first characters of the invoices project name in the Project field. 

Note, only the shared integration, get Invoice, is available for selection as a tool. 

The tools mgr user can change the description etc. -

The tools manager now enables the dedicated tools project as an MCP server.

Govern Access via MCP Gateway

The OIC MCP Gateway policies govern access to the published tools.

This gateway can front multiple MCP servers, including the project MCP server we just enabled. 

Please see my posts on the Gateway for details on how to configure etc.

Summa Summarum

Exposing an integration as an agent tool takes just a few clicks. Deciding what to expose, who should publish it, and how agents should access it deserves a deliberate approach.

The pattern demonstrated here gives integration owners and tools managers clear responsibilities. Integration owners select which assets to share and grant the required project access. Tools managers build a dedicated tools project from those shared assets, refine the tool descriptions, and expose the project as an MCP server. The MCP Gateway then provides the policies governing access to those tools.

The value is straightforward: reuse existing integration logic while retaining control over which capabilities become available to agents. Integration developers can focus on delivering business functionality, while tools managers shape how that functionality is presented for agent use.

Try it with one shared integration and a dedicated tools project. Validate the permissions from the tools manager’s account, then configure and test gateway access. You now have a repeatable approach for expanding your agent toolkit with clear ownership and governance.