How it works
How you work with connubes
A data transfer is not written as a program but set up as a configuration: connect source and target, map the fields, set the trigger, test. What that takes — and what it explicitly does not.
The sequence
A transfer in five steps
The first one takes credentials and half an hour. For every further transfer on the same system, step 1 falls away.
A schematic view of the canvas — screenshots from the designer will follow.
Set up the connection
Pick a plug-in, enter address and credentials, check the connection. That happens once per system, not once per transfer.
Build the transfer
Drag source and target onto the canvas. From the outside every transfer looks the same; inside it is cut to fit its system.
Map the fields
The data fields are browsed in the target system and taken over rather than typed in — whole structures too. That way a field name cannot be mistyped.
Set the trigger
You decide when the transfer runs: on a schedule, on a value change, on an event, or on demand.
Test it and put it live
A trial run shows what actually arrives. After that the transfer keeps running as a service and reports its state.
The difference
Configure instead of program
A one-off integration goes through specification, development, testing, acceptance and operation. Of those five steps, two remain here: configure and operate. The effort moves from weeks to hours.
The practical difference only shows later, though: who changed the connection and why is in the configuration — not in the head of whoever wrote it.
What does NOT happen
The controller is not reprogrammed. The data is picked up through the interfaces the machine already has — nothing is changed inside the machine, and the line does not have to stop for it.
The trigger
You decide when a transfer runs
The trigger is where a connection becomes a sequence. Four kinds cover practice — combinable, when a transfer has more than one occasion.
| Trigger | Runs when … | Typical for |
|---|---|---|
| On a schedule | a schedule says so | Shift reports, nightly reconciliation, cyclic readings |
| Value change | a value at the controller changes | Status messages, faults, piece counters |
| Event | a system reports an event | Order release from the ERP, test result from the measuring station |
| On demand | someone or something calls it | A request from an application, a manual re-run |
On the way
Data rarely arrives in the shape it is needed in
Between source and target sits the transformation. There are tools for it rather than code: XML and XPath, JSON and JPath, CSV — and, where a rule really is one of a kind, a .NET or C# script.
The order is deliberate: the script comes only when none of the three standard tools carries. Every line written by hand is a line someone has to understand again in five years.
In operation
Seeing that it runs
A transfer that quietly stops is worse than one that was never built. So each one reports its state: status and diagnosis per transfer, with the time of the last run. Fault finding therefore starts at the answer, not at the question.
A schematic view of the status list — the screenshot will follow here too.
Two add-ons belong to operation: Store & Forward buffers on a dropped connection and delivers once it is back. Redundancy keeps a second instance ready where an outage is out of the question.
Common questions
Answered briefly
Does the controller have to be reprogrammed for this?
No. The data is picked up through the interfaces the controller already has. Nothing is changed inside the machine.
Do I need developers for this?
Not for the normal case. Anyone who knows their systems can configure a transfer. Programming knowledge is only needed once a transformation goes beyond XPath, JPath and CSV.
How long does the first transfer take?
With the credentials to hand and the system reachable: half an hour. The second one on the same system takes minutes, because the connection is already there.
Does it work in both directions?
Yes. Orders from the ERP to the line, setpoints to the controller, feedback to the control room — the same path, the other way round.
Where does connubes itself run?
Platform-independently on Windows, in Docker or in Kubernetes — on a machine in the plant just as well as in the cloud.
