> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-5-0/guides/migration/migrating-from-soffico-orchestra.md). # Migrating from soffico Orchestra This guide shows you how to migrate the industrial connectivity portion of a soffico Orchestra installation to Connectware by compiling an inventory of your scenarios and communication adapters and translating it into a [service commissioning file](/2-5-0/data-flows/service-commissioning-files.md). Orchestra stores scenarios in a format that is not documented as a stable interface, so the migration works from an inventory that you compile in the Orchestra Designer, supplemented with screenshots of the scenario canvas and adapter configurations. In more detail, the following topics are covered: * Understanding how Orchestra concepts map to Connectware resources * Compiling a scenario inventory from the Orchestra Designer * Translating the inventory into a service commissioning file with an AI assistant * Reviewing the generated service commissioning file * Verifying the migrated data points in the [Data Explorer](/2-5-0/monitoring/data-explorer.md) A complete worked example, from scenario inventory to service commissioning file, is available at the end of this guide. ## Prerequisites To follow this guide, you will need the following: * A running instance of Cybus Connectware with licenses for the connectors that replace your Orchestra adapters. * Access to the Orchestra Designer and the adapter configurations of your Orchestra installation. * Network access from Connectware to the systems that Orchestra currently talks to. * An AI assistant to translate the inventory. Any capable large language model (LLM) works. [Cybus Connectware GPT](/2-5-0/tools/cybus-connectware-gpt.md) is a ChatGPT assistant that already knows the service commissioning file format. * Basic knowledge of the Connectware [services](/2-5-0/data-flows/services.md) concept (for example, [service commissioning files](/2-5-0/data-flows/service-commissioning-files.md), [connections](/2-5-0/data-flows/service-commissioning-files/resources/cybus-connection.md), and [endpoints](/2-5-0/data-flows/service-commissioning-files/resources/cybus-endpoint.md)). ## How Orchestra Concepts Map to Connectware Orchestra organizes integration in scenarios: graphical message flows that receive data through communication adapters, transform it with mapper and script nodes, and deliver it through other adapters. Connectware organizes the same information in resources of a service commissioning file: | Orchestra concept | Connectware resource | Notes | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Communication adapter (configured system access) | [Cybus::Connection](/2-5-0/data-flows/service-commissioning-files/resources/cybus-connection.md) | The adapter settings (endpoint URL, host, security configuration) become the connection properties. | | Data point or address used by an adapter | [Cybus::Endpoint](/2-5-0/data-flows/service-commissioning-files/resources/cybus-endpoint.md) | Each OPC UA node, database field, or REST resource becomes an endpoint. | | Scenario (message flow between adapters) | [Cybus::Mapping](/2-5-0/data-flows/service-commissioning-files/resources/cybus-mapping.md) | Straight source-to-target flows become mappings; flows with logic need [Rule Engine](/2-5-0/data-flows/rule-engine.md) rules. | | Mapper transformations | Rule Engine `transform` rule | Field renaming and restructuring becomes a JSONata expression. | | Timer-triggered scenario start | Polling interval | The timer period becomes the endpoint interval, or the sampling interval for OPC UA. | | Inbound HTTP or web service trigger | [HTTP Server](/2-5-0/connectors/servers/http-server.md) | Inbound calls that start a scenario become HTTP Server resources. | | Script nodes | Rule Engine or [Node-RED Workbench](/2-5-0/data-flows/node-red-workbench.md) | Scripted logic has no mechanical translation. | | Request-response flows with confirmations | [FlowSync](/2-5-0/data-flows/flowsync.md) | Transactional flows across systems become FlowSync services. | | Environment-specific scenario settings | Parameters and definitions with `!sub` | One service commissioning file per scenario template; one parameter set per deployment. | ### Mapping Adapters to Connectors The following Orchestra adapter types have a native Connectware counterpart: | Orchestra adapter | Connectware connector | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | OPC UA | [OPC UA Client](/2-5-0/connectors/shop-floor-connectors/opc-ua/opc-ua-client.md) | | MQTT | [MQTT](/2-5-0/connectors/enterprise-connectors/mqtt.md) | | REST/HTTP(S) | [HTTP/REST](/2-5-0/connectors/enterprise-connectors/http-rest.md) and [HTTP Server](/2-5-0/connectors/servers/http-server.md) | | Database (JDBC) | [MSSQL](/2-5-0/connectors/enterprise-connectors/mssql.md) for SQL Server, [SQL](/2-5-0/connectors/enterprise-connectors/sql.md) for MySQL/MariaDB and PostgreSQL | | Apache Kafka | [Kafka](/2-5-0/connectors/enterprise-connectors/kafka.md) | If Orchestra reaches PLCs through intermediary OPC servers or gateway software, the migration is an opportunity to remove them: Connectware connects to [S7](/2-5-0/connectors/shop-floor-connectors/siemens-simatic-s7.md), [Modbus/TCP](/2-5-0/connectors/shop-floor-connectors/modbus-tcp.md), and [EtherNet/IP](/2-5-0/connectors/shop-floor-connectors/ethernet-ip.md) devices natively. If a KEPServerEX instance sits between Orchestra and the machines, see [Migrating from Kepware KEPServerEX](/2-5-0/guides/migration/migrating-from-kepware-kepserverex.md). ### What Does Not Migrate 1:1 | Orchestra feature | Connectware approach | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | File and FTP adapters | No counterpart. Connectware moves data over protocols, not files; deliver the data to a consuming system over MQTT or HTTP instead. | | SOAP web services | No dedicated SOAP support. Simple SOAP calls can be built as XML bodies with the [HTTP/REST connector](/2-5-0/connectors/enterprise-connectors/http-rest.md); complex ones need a redesign. | | SAP adapters (RFC, IDoc) | No counterpart. Integrate SAP through its HTTP-based APIs with the [HTTP/REST connector](/2-5-0/connectors/enterprise-connectors/http-rest.md) or an external integration layer. | | Healthcare adapters (HL7, DICOM) | No counterpart. Connectware targets industrial connectivity; keep healthcare integration in a dedicated system. | | Email and notification steps | Route alerts to a consuming system over MQTT or HTTP. | | Script nodes and branching scenario logic | Re-implement in the [Node-RED Workbench](/2-5-0/data-flows/node-red-workbench.md) or with [FlowSync](/2-5-0/data-flows/flowsync.md) for request-response orchestration. | | Long-running processes with manual steps | Process orchestration with human interaction stays in a workflow system; Connectware handles the data flows underneath. | ## Compiling a Scenario Inventory Orchestra scenario files are not documented as a stable interface, so do not build the migration on parsing them. Compile an inventory instead. For each scenario that moves industrial data, record: 1. The trigger: timer period, data change, or inbound call. 2. The source adapter with its configuration: adapter type, endpoint URL or host, security settings, and the data points or addresses it reads. 3. The transformation: what the mapper or script nodes do with the message, in one or two sentences. 4. The target adapter with its configuration and the resources it writes to. Capture the adapter configuration dialogs and the scenario canvas as screenshots; they carry the details that the inventory table summarizes. If your Orchestra version can export scenario documentation from the Designer, use it as the starting point for the inventory. {% hint style="warning" %} Credentials are not part of the migration material. Collect endpoint URLs, users, and certificates separately, and remove any credentials from screenshots and exports before you paste them into an AI tool. Check the data privacy terms of the tool you use; see also the privacy notes for [Cybus Connectware GPT](/2-5-0/tools/cybus-connectware-gpt.md#data-privacy). {% endhint %} ## Translating the Inventory with an AI Assistant Copy the following prompt and attach the inventory and the screenshots: {% code title="AI translation prompt" lineNumbers="true" expandable="true" %} ``` You are translating an inventory of soffico Orchestra scenarios into a Cybus Connectware service commissioning file (YAML). The inventory lists scenarios with their triggers, source and target communication adapters, data points, and transformations. Screenshots of the scenario canvas and adapter configurations are attached. Produce one complete, valid service commissioning file with description, metadata, parameters, definitions, and resources. Structural rules: - Create one Cybus::Connection per communication adapter that has a Connectware connector: OPC UA -> Opcua, MQTT -> Mqtt, REST/HTTP -> Http, Microsoft SQL Server -> Mssql, other JDBC databases -> Sql, Kafka -> Kafka. Take host, port, and security settings from the adapter configuration. - Create one Cybus::Endpoint per data point, address, or REST resource that a scenario reads or writes. - Timer triggers become the polling or sampling interval of the source endpoints; data change triggers use the default subscription behavior of the connector. - Straight source-to-target scenarios become Cybus::Mapping entries publishing each endpoint to a topic derived from the scenario and data point names, lowercase kebab-case. Simple mapper transformations (renaming, restructuring, unit conversion) become JSONata expressions in transform rules. - Scenarios with script nodes, branching, or logic that the inventory cannot express cannot be translated mechanically: list them under "Needs redesign" with a short description of what they do. - Inbound HTTP triggers become HTTP Server resources. - Define hosts and credentials as parameters, never hardcoded. Do not include any credentials in the output. - Skip adapters without a Connectware counterpart (files, FTP, SAP, email, healthcare) and list them at the end under "Not migrated". After the YAML, output a migration report: number of adapters, data points, and scenarios translated, all assumptions made, and every flagged item that needs manual review or redesign. [Attach the scenario inventory and the screenshots. State your Orchestra version.] ``` {% endcode %} For large installations, translate one scenario at a time and combine the results. Expect scenarios with files, SAP, or scripts to need a redesign discussion rather than a translation. ## Reviewing the Generated Service Commissioning File Work through this checklist before installing: 1. Validate the file structure. The [Cybus Connectware Extension for VS Code](/2-5-0/tools/cybus-connectware-extension-vs-code.md) validates service commissioning files against the official schemas as you edit. 2. Check every connection against the original adapter configuration: endpoint URL, security settings, and database host. 3. Spot-check translated OPC UA addresses with an OPC UA browser as described in [Using Connectware as an OPC UA Client](/2-5-0/guides/system-connectivity/industry-standards-interoperability/using-connectware-as-an-opc-ua-client.md). 4. Review every scenario listed under "Needs redesign" and decide where its logic goes: Rule Engine, Node-RED Workbench, FlowSync, or a consuming system. 5. Re-enter all credentials as parameters; they were not part of the migration material. 6. Compare the endpoint count against the migration report of the AI assistant and the data point count of your inventory. ## Installing the Service 1. Install the service commissioning file. See [Installing Services](/2-5-0/data-flows/services/managing/installing.md). 2. Enable the service. See [Enabling Services](/2-5-0/data-flows/services/managing/enabling.md). **Result:** Connectware connects to the migrated systems directly and the connections reach the **Connected** state. {% hint style="info" %} For read-only validation, Connectware and Orchestra can usually read the same OPC UA servers and databases at the same time, which allows you to compare live values before you disable the original scenarios. Check the session limits of your OPC UA servers first. {% endhint %} ## Verifying the Data Open the [Data Explorer](/2-5-0/monitoring/data-explorer.md) and subscribe to the topics of the migrated service: * Every migrated data point publishes on its topic with plausible values. * Values match between Orchestra and Connectware for the same data point. * Target-bound flows write the expected data through the HTTP and SQL connectors, visible on the `/res` topics of the write endpoints. * Data arrives at the original trigger rates. ## Worked Example The following inventory describes a single Orchestra scenario that reads two data points from a press PLC over OPC UA every five seconds, renames the speed field in a mapper node, and posts the speed to a manufacturing execution system (MES) over REST: | Item | Value | | -------------- | -------------------------------------------------------------------------------------- | | Scenario | Press to MES | | Trigger | Timer, 5000 ms | | Source adapter | OPC UA, `opc.tcp://192.168.1.100:4840`, security None | | Data points | `ns=2;s=Press.Speed`, `ns=2;s=Press.PiecesOut` | | Transformation | Mapper renames the speed value to the MES field names (`machine`, `metric`, `reading`) | | Target adapter | REST, `https://mes.example.com`, POST to `/api/production-events`, speed values only | Applying the translation rules produces the following service commissioning file. The two communication adapters become an OPC UA and an HTTP connection, each data point becomes an endpoint with the timer period as sampling interval, and the scenario routing becomes a mapping whose `transform` rule replaces the mapper node: {% file src="/files/kerOMC8Fu83xTa9mxJbb" %} {% code title="soffico-orchestra-migration-example.yml" lineNumbers="true" expandable="true" %} ```yaml description: > Service commissioning file migrated from the Orchestra scenario "Press to MES" (Example) metadata: name: Orchestra Migration Example provider: cybus homepage: https://www.cybus.io version: 1.0.0 parameters: opcuaHost: description: Host of the OPC UA communication adapter target type: string default: 192.168.1.100 opcuaPort: description: Port of the OPC UA communication adapter target type: integer default: 4840 mesHost: description: Host of the MES REST API type: string default: mes.example.com definitions: MQTT_TOPIC_PREFIX: press-to-mes resources: # Orchestra communication adapter "Press-PLC" (OPC UA, security None) opcuaConnection: type: Cybus::Connection properties: protocol: Opcua targetState: connected connection: host: !ref opcuaHost port: !ref opcuaPort options: securityPolicy: None messageSecurityMode: None # Data point Press/Speed; the 5000 ms timer of the scenario becomes # the sampling interval pressSpeed: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: nodeId: ns=2;s=Press.Speed samplingInterval: 5000 publishInterval: 5000 # Data point Press/PiecesOut pressPiecesOut: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: nodeId: ns=2;s=Press.PiecesOut samplingInterval: 5000 publishInterval: 5000 # Orchestra communication adapter "MES" (REST) mesConnection: type: Cybus::Connection properties: protocol: Http connection: scheme: https host: !ref mesHost port: 443 # Target of the scenario: POST to the MES production events resource mesWrite: type: Cybus::Endpoint properties: protocol: Http connection: !ref mesConnection write: path: /api/production-events # The scenario routing: both data points into the UNS, the speed # value also to the MES. The transform rule replaces the mapper node # of the scenario, which renamed the field for the MES. mapping: type: Cybus::Mapping properties: mappings: - subscribe: endpoint: !ref pressSpeed publish: topic: !sub '${MQTT_TOPIC_PREFIX}/speed' - subscribe: endpoint: !ref pressPiecesOut publish: topic: !sub '${MQTT_TOPIC_PREFIX}/pieces-out' - subscribe: endpoint: !ref pressSpeed publish: endpoint: !ref mesWrite rules: - transform: expression: >- { "body": { "machine": "press-01", "metric": "speed", "reading": value } } ``` {% endcode %} For all OPC UA connection and endpoint properties, see [OPC UA Connection Properties](/2-5-0/connectors/shop-floor-connectors/opc-ua/opc-ua-client/opcuaconnection.md) and [OPC UA Endpoint Properties](/2-5-0/connectors/shop-floor-connectors/opc-ua/opc-ua-client/opcuaendpoint.md). {% hint style="info" %} Disclaimer: Orchestra is a product of soffico GmbH. All product and company names are trademarks or registered trademarks of their respective owners. Cybus is not affiliated with soffico GmbH. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cybus.io/2-5-0/guides/migration/migrating-from-soffico-orchestra.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.