Articles

Open-Source Oracle SOA Suite Alternative (in Python)

Premier Support for Oracle SOA Suite 12c ends in December 2026, and Extended Support in December 2027.

This article describes the two paths Oracle offers, maps SOA Suite concepts to an open-source platform in Python and presents a sequence for moving SOA composites to it.

By Dariusz Suchojad

10 min. read

Share this article:LinkedIn | FB | Email

Oracle SOA Suite runs the integrations of many organizations that use Oracle E-Business Suite, Oracle Database and the other Oracle products. A SOA composite combines BPEL processes, Mediator components, business rules and adapters for databases, files, FTP servers and JMS queues, and Oracle Service Bus exposes and routes the services through proxy and business services. Messages are transformed with XSLT and XQuery, composites are designed in JDeveloper, and the composites run on Oracle WebLogic Server, with the state of each process stored in the SOA infrastructure schemas of an Oracle database.

The end of Premier Support for SOA Suite 12c

In June 2025, Oracle extended the support dates of SOA Suite 12.2.1.4, the last release of SOA Suite 12c. The Oracle Fusion Middleware Statement of Direction of May 2026 confirms the dates for 12c and for its successor:

After December 31, 2026, Oracle delivers no further full updates and no quarterly security fixes for SOA Suite 12.2.1.4, and after December 2027 no updates or security fixes of any kind. Oracle intends to offer a Market Driven Support program for 12.2.1.4 on a yearly basis beyond 2027, with the details to be communicated later.

An organization on SOA Suite 12c therefore chooses between two paths offered by Oracle - an upgrade to SOA Suite 14.1.2 or a move to Oracle Integration, the integration service of Oracle Cloud.

What the upgrade to SOA Suite 14.1.2 involves

Oracle states that an upgrade from 12c to 14.1.2 requires a complete upgrade and is not a patch set. The middle tier and the database schemas are upgraded together, and the schemas and domain directories are upgraded in place. Domains that include SOA Core Extension or Oracle Enterprise Repository cannot be upgraded in place and are migrated side by side.

The platform underneath changes as well. WebLogic Server 14.1.2 runs on JDK 17 or JDK 21, and the WebLogic Server Administration Console is removed in favor of the WebLogic Remote Console.

The Statement of Direction also announces the next suite release, Fusion Middleware 27, targeted for 2027 and built on a Jakarta EE 11 container. An organization that upgrades to 14.1.2 now plans the following upgrade in the same document.

What the move to Oracle Integration involves

Oracle's own architecture team states that a move from SOA Suite to Oracle Integration is not an upgrade or an automatic migration. The two products have different design-time and runtime environments, and the integrations are developed again in Oracle Integration, with BPEL processes, Mediator components and Service Bus pipelines rebuilt as orchestrations in its visual designer.

Oracle Integration is billed in message packs of 5,000 billing messages per hour for a new license, or 20,000 billing messages per hour for an existing Fusion Middleware license brought to the cloud. The service also changes generation on Oracle's schedule. Oracle Integration Generation 2 was discontinued on August 31, 2025, and its customers upgraded to Oracle Integration 3.

Because each composite is rebuilt on the cloud path in any case, the choice of the target platform is open, and the integrations can be rebuilt in Python, on an open-source platform, on your own infrastructure.

From JDeveloper to Python

A single SOA composite consists of several kinds of artifacts. The composite definition, a BPEL process drawn in the JDeveloper designer, XSD schemas and WSDL interfaces for each message, XSLT maps, adapter configuration files, a configuration plan for each environment, and in many installations a Service Bus project with its own pipelines and XQuery transformations. The logic of one business process is spread across graphical designers and XML files of different formats, and it is deployed as a SOA archive to WebLogic Server.

SOA Suite belongs to the generation of integration products built on Java EE application servers and graphical designers. The process logic is written in BPEL, the data mapping in XSLT or XQuery and the custom code in Java, each with its own tools and its own specialists.

In Zato, an integration is a Python service. Python is the most widely used programming language - first in the TIOBE index for October 2026, and used extensively by 58 percent of the developers who answered the 2026 Stack Overflow Developer Survey. Python is also the language of data, machine learning and AI agents, the next generation of integration.

An integration in Python is one file that any Python developer reads, reviewed like any other code, versioned in Git and written fluently by AI assistants. It is developed in the IDE of your choice and tested with the built-in testing framework. Channels, connections and security definitions are configured in the Dashboard, which also shows the audit log of every message that the integrations process.

SOA Suite concepts and their Zato counterparts

A BPEL process rewritten in Python

A typical BPEL process receives a shipment notice from a logistics provider, updates the order in the Oracle database of the ERP through the Database adapter, sends the tracking details to the CRM and publishes the event for the other systems that subscribe to it. In SOA Suite, this process requires a composite, a BPEL process, XSD schemas, a WSDL interface, an XSLT map, a Database adapter configuration and a configuration plan.

In Zato, the same process is one Python file:

# -*- coding: utf-8 -*-

# stdlib
from dataclasses import dataclass

# Zato
from zato.server.service import Model, Service

@dataclass(init=False)
class ShipmentNotice(Model):
    order_number: str
    carrier: str
    tracking_number: str

class ProcessShipmentNotice(Service):
    """ Records shipments in the ERP and sends their tracking details to the CRM.
    """
    name = 'orders.process-shipment-notice'
    input = ShipmentNotice

    def handle(self) -> 'None':

        notice = self.request.input

        # The order is marked as shipped in the ERP database ..
        conn = self.out.sql['ERP']

        query = """
            UPDATE orders
            SET status = 'SHIPPED', tracking_number = :tracking_number
            WHERE order_number = :order_number
        """

        params = {
            'order_number': notice.order_number,
            'tracking_number': notice.tracking_number,
        }

        conn.execute(query, params)

        # .. the CRM receives the tracking details ..
        tracking = {
            'order': notice.order_number,
            'carrier': notice.carrier,
            'tracking_number': notice.tracking_number,
        }

        self.rest['CRM'].post(tracking)

        # .. and every subscriber to shipped orders receives the notice.
        self.publish('orders.shipped', notice)

The tutorial builds a complete integration of this kind, from an empty environment to a working API.

Converting SOA composites with AI

Composites, BPEL processes, XSLT maps, XQuery transformations, schemas and adapter configurations are XML files, and AI assistants translate them into Python services. An AI assistant reads the artifacts of a composite or a Service Bus project and writes one Python service per process, with the maps expressed as Python code and the schemas as data models. With the Zato documentation connected to it over MCP, the assistant uses the real APIs of the platform.

Each converted service is then reviewed by your developers and tested with messages from the production SOA Suite environment. The same message is processed by the composite and by the Python service, and the outputs are compared before the Python service receives live traffic.

The migration sequence

A migration from SOA Suite proceeds one composite at a time, with both platforms running side by side for as long as it takes:

1. Inventory the composites. For each composite and Service Bus project, record its services, references, BPEL processes, transformations, adapters, business rules and configuration plans.
2. Define the connections. Every reference, adapter and business service becomes an outgoing connection in Zato, and every exposed service and proxy service becomes a channel, defined for each environment in YAML.
3. Convert the composites with AI. An AI assistant translates the BPEL processes, Mediator routing and transformations into Python services, and your developers review each service.
4. Move the business rules. Each Oracle Business Rules dictionary becomes a ruleset of the rule engine, which services evaluate at runtime.
5. Test with production messages. Messages from the production composites are sent to the new services, and their outputs are compared with the outputs of SOA Suite.
6. Switch the endpoints. Each calling system, trading partner, file location and queue is pointed to the Zato channel in turn.
7. Retire the SOA domain. When the last composite carries no more traffic, the WebLogic servers and the SOA infrastructure schemas are shut down.

Where Zato runs

Zato runs on your own infrastructure - on physical or virtual servers, in Docker, in Kubernetes and in any cloud, including Oracle Cloud Infrastructure. It connects to Oracle Database with queries and stored procedures, including REF CURSOR result sets, and to the SAP, REST, SOAP, file transfer and message queue systems that SOA composites integrate.

EDIFACT messages from trading partners, such as ORDERS, DESADV and INVOIC, are parsed into Python objects, routed by message type and serialized back byte for byte, in the same services that call the ERP, the database and the REST APIs of the organization.

Integrations are Python code and YAML configuration in your own Git repository. Enterprise support is available 24x7x365 from the team that builds Zato.

Oracle SOA Suite and Zato compared

Frequently asked questions

When does support for Oracle SOA Suite 12c end?

Premier Support for SOA Suite 12.2.1.4 ends on December 31, 2026, and Extended Support in December 2027. Oracle intends to offer a yearly Market Driven Support program for 12.2.1.4 beyond 2027.

Can SOA composites be moved to Oracle Integration automatically?

No. Oracle states that the move from SOA Suite to Oracle Integration is not an upgrade or an automatic migration, and the integrations are developed again in Oracle Integration.

Can AI convert BPEL processes and XSLT maps to Python?

Yes. An AI assistant translates BPEL processes, Mediator routing, XSLT maps and XQuery transformations into Zato services, and with the Zato documentation connected to it over MCP, it uses the real APIs of the platform. Your developers review each service and test it with messages from the production composite before it takes over the traffic.

Does Zato process EDIFACT messages?

Yes. Zato parses EDIFACT interchanges into Python objects, routes messages by type and serializes them back byte for byte, as shown in the EDIFACT tutorial.

Can Zato and SOA Suite run at the same time?

Yes. During a migration both platforms run side by side, and endpoints are moved to Zato one composite at a time.

Is Zato open source?

Yes. The source code of Zato is on GitHub.

How do I get started?

Start the tutorial or schedule a demo.

Dariusz Suchojad is founder of Zato Source.