Integrating Subiekt GT with a web application: what to agree before implementation

If your team has to re-enter orders from a web application into Subiekt GT, start by agreeing which data should move between the systems, who can change it and how staff will know an operation has succeeded. Those decisions give you a basis for choosing an existing connector or estimating a custom integration. Sending an order does not, by itself, confirm that the right document has been created or that fulfilment can begin.

You also need to decide what happens when the connection is unavailable. A shop or portal may continue accepting orders while the component communicating with Subiekt is offline, but pending operations need somewhere to wait, and staff need to be able to see the delay. These arrangements affect how your sales team works as well as how the two applications connect.

Does Subiekt GT have an API for web applications?

InsERT provides Sfera for Subiekt GT, an add-on for building extensions that use the application's own functions, including online shop order processing. Sfera gives a developer access to Subiekt's functions. It is not a ready-made web service that you can simply call from a browser.

InsERT's technical documentation describes COM and OLE Automation: mechanisms that allow another program to call Subiekt's functions. Connecting a web application therefore requires a component that works with Sfera and a way for the web application to communicate with it. An existing connector or custom software can provide the web API. A proposal should clearly state who supplies that component and who is responsible for updating it.

Subiekt GT Sfera has Windows and Microsoft SQL Server requirements. The web application can run in a different environment, but the component working with Subiekt still needs to be maintained. Agree which computer or server will run it, when it needs to be available and who will restore it after a failure.

Which data should be shared, and which system can change it?

Instead of asking to “synchronise everything”, describe one complete order workflow. Where is the order created? When is it confirmed? Which document should appear in Subiekt, and what information should return to the application? Separately, agree what happens when quantities change, an order is cancelled or goods are returned. Sending the initial order does not cover everything that happens to it afterwards.

Each type of data needs an agreed source. If your team sets prices in Subiekt but maintains product descriptions in the shop, the integration should respect that division. When people can edit the same field independently in both systems, you need a rule for resolving conflicts or referring them to a member of staff. Simply choosing the value with the later timestamp can overwrite a deliberate decision made by someone else.

You also need to agree product and customer identifiers, sales units, warehouses, discounts, and how amounts and tax rates are transferred. For example, one pack in the application might represent several individual items in the warehouse. Test that situation with sample data before the integration starts creating documents.

Define separately what the stock figure shown in the shop means. Is it the physical quantity in the warehouse, the quantity after reservations, or another measure of stock available to sell? Specify how much delay is acceptable and what should happen when current data is unavailable. Periodically fetching stock levels does not, on its own, prevent several customers from ordering the last item.

What if the order was saved but the confirmation never arrived?

Include this scenario in your acceptance tests: Subiekt saves the document, then the connection drops. The application receives no response and tries to send the order again. Unless the integration recognises the earlier operation, it may create a duplicate.

Ask the supplier to demonstrate how the integration recognises a retry and determines the outcome of the earlier attempt. A stable operation identifier is one part of the solution; AWS explains this principle in its guide to safe retries. Recording an order number in a log is not enough. There must be a tested way to link it to the document and resolve cases where the result is uncertain.

Distinguish a brief connection failure from invalid data, such as an unknown product. Microsoft's retry guidance recommends retrying transient failures with suitable delays and a limit on attempts. Invalid data needs correcting. Staff should be able to see which order is waiting, why it is waiting and who needs to deal with it.

If someone enters an order manually during an outage, the recovery procedure needs to account for that. Otherwise, once the connection returns, the integration may repeat work that has already been completed. Agree how staff will mark these cases and reconcile pending orders.

An existing connector or a custom integration?

Assess an existing product against your actual order workflow. Ask for a demonstration covering your warehouse, document types, changes and returns, as well as interrupted connections. A list of supported systems does not tell you whether the product fits the way your business works.

A custom integration makes sense when available products cannot handle the process you need, or when their limitations leave a substantial amount of manual work. The estimate should include testing, error handling, documentation and maintenance. Responsibility for this work continues after the integration goes live.

Before comparing proposals, check your Subiekt version and licensing terms. InsERT describes Sfera for Subiekt GT as a single-workstation licence that can be extended. Ask the supplier to confirm the licences required for the proposed installation. Alongside development costs, allow for maintaining the environment, any connector fees and compatibility checks after updates.

When documents are created, expect the integration to use application functions that apply Subiekt's business rules. If a proposal includes direct database operations, the supplier should explain their scope, their effect on data consistency and how they will be maintained when versions change. Reading data for a report and writing a sales document need separate assessments.

How should you test the integration before launch?

In a test environment, follow an order from the web application through to the document in Subiekt and the confirmation shown to staff. Check the product, quantity, price, discount, warehouse and agreed effects of the operation. Acceptance tests should also cover resending the same order, a missing product, an amended order and an interrupted connection. Record the expected result for each case.

Test recovery after restarting the integration component, processing pending operations and handling the expected peak in orders. Timing requirements should measure completion of the required operation, rather than just acceptance into a sending queue. Involve the person who will deal with exceptions in day-to-day work.

Access to the web API should require authentication and permission for each operation. OWASP's REST security guidance covers HTTPS and protecting credentials. Subiekt credentials and confidential integration keys should stay on the server, out of browser code and URLs. Logs need to provide a record of operations without unnecessarily copying customer data.

Who is responsible after the integration goes live?

Agree on a single route for reporting problems, even if different companies maintain the shop, Subiekt and the integration. It should be clear who investigates errors, who corrects data, who can retry an operation and who confirms that pending work has been cleared. Agree the scope of support and the tests needed after updates to Subiekt, the connector or the web application.

To prepare for an estimate, gather your Subiekt version and deployment details, a description of the documents you use, and examples of a normal order and exceptions. The first stage of a system and API integration can establish data flows, constraints and acceptance criteria. This gives you a basis for comparing proposals according to how they will improve order processing and help staff manage cases that need attention.