APIs & synchronisation.Keep shared dataconsistent.
When several systems use the same information, the authoritative source and update rules must be clear. SIXIS organises and implements these exchanges using available interfaces and your company’s rules.
When several systems use the same information, the authoritative source and update rules must be clear. SIXIS organises and implements these exchanges using available interfaces and your company’s rules.
Tell us what data differs See how we workWhen the same information
has different values.
Synchronization involves more than the periodic copying of some fields. We need to know who can change the data and what happens if the sources disagree.
A change does not reach everywhere.
A price, quantity, or address is updated in the reference system but remains old in another application. The team works with different information and has to manually check which variant can be used.
Records not consistently recognized.
The same product or customer has different identifiers. An import creates a new copy instead of updating the existing record. Over time, the differences accumulate and it becomes difficult to determine which data belong to the same case.
The resumption of an exchange produces conflicts.
A system was unavailable, and changes are resubmitted after coming back. If the order and authoritative source are not clear, an older value may replace the new one, or incomplete information may erase valid data.
Correct source.
Updates verifiable.
We establish each field's authority and update rules before maintaining data between systems.
The API is a method by which systems can communicate. The technical choice depends on what the applications allow, volume and actual upgrade requirements.
The SIXIS collaboration modelWe delineate dates and directions.
We choose the necessary records and fields, reference source and destinations. We determine who can change each piece of information. We separate one-way exchanges from cases where both systems can produce updates and a conflict must be resolved.
From you Systems involved and firm rules regarding reference data.
We check interfaces and boundaries.
We review documentation, permitted operations, and required access. We check identifiers, volumes and possible exchange frequency. We determine how access is kept secure and whether costs or provider interventions are required for the agreed exchange.
From you Available documentation, authorized access, and persons responsible for systems.
We define identification and updating.
Establish correspondence of records, validations and order of changes. We specify what a missing value, a new record or a deleted one means. We define the frequency and what happens when an update is delayed or received multiple times.
From you Fixed identifiers and rules for changes, cancellations or deletions.
We test differences and resume.
We check for new data, simultaneous changes, incomplete information, and interruptions. We confirm that replay does not duplicate records or replace a new value with an old one. Cases that cannot be resolved by the approved rules are flagged for verification.
From you Test cases and data validation in participating systems.
We follow the concordance after starting.
We check the exchanges, the remaining differences and the time of the last update. We determine who resolves conflicts and who is notified of outages. Structure or permission changes are evaluated before continuing to sync in the same form.
From you Responsible for Data and Agreed Exchange Maintenance Area.
A WORKING EXAMPLE
A catalogue.
Pricing and availability.
A distributor uses an online catalog and management system. Prices and availability must be updated according to agreed sources, without confusing commercial data with operational bookings.
- The product has a stable identification.
- The agreed code links the records in the two systems. If a product can't be paired, it goes to checkout. A new product is not automatically created just because the name is slightly different.
- Every field has a source.
- The price and quantity that can be displayed are taken according to the rules of the company. An edited description in the catalog is not overwritten if that field is not part of the exchange. A missing value is not automatically interpreted as a zero price.
- The interruption remains visible.
- If the update fails, the person in charge sees what data is left behind. On replay, shifts are checked in the required order. The catalog is not presented as permanently updated if the source only allows periodic updates.
RELATED CAPABILITIES
What it supports
exchange of data.
Technical synchronization must be related to the meaning of the information and how the team uses it in the company's processes.
Integrations
Delineates the necessary connections and transfers between the firm's systems.
CRM / ERP flows
Clarifies sources and states used between business activity and operations.
Inventory & logistics
Determines what quantities may be considered available, reserved or on check.
Dashboards
Can show validated data and when it was updated for team decisions.
Questions about
data and updates.
What can be maintained in the agreement and how we treat information that does not match.
What is an API, in practical terms?
An interface through which one system allows another system to read data or perform certain operations. Available features differ between apps. The existence of an API does not mean that any information can be modified or that the desired exchange is possible without limits.
Must synchronization be real-time?
Only if the activity requires it and the systems allow it. We may use updates at the event or at agreed intervals. Frequency is chosen based on utility, volume and limits. The time of the last update must be known when the team uses the data for a decision.
How do you decide which system has the correct value?
The firm validates the reference source for each piece of information. Some fields may belong to one system and some to another. If the same information can be changed in both places, we define the conflict rule. We do not assume that the last value received is always the correct one.
What happens to existing duplicates?
We identify the association rules and evaluate the cleanup of old data separately. A new exchange does not automatically resolve an inconsistent history. Records that cannot be linked securely must be verified, and their joining requires confirmation of the effect on already linked information and documents.
Can missing data delete information from the other system?
Only if there is an explicit and validated rule for that case. We distinguish the lack of information from a request to empty or delete. We test these situations before startup because a seemingly simple update can affect valid data or links used by other processes.
How to resume synchronization after an interruption?
We determine which exchanges can be resumed and how we check the operations already done. The identification and order of updates must prevent duplication or reverting to old values. Cases that cannot be safely reconciled are forwarded to the responsible person, with the necessary data for verification.
Is synchronization of all fields and history included?
Not automatically. We delineate the required fields, records, directions and period. The initial transfer of a history may have different checks and costs than the current update. We choose the data that supports the activity, without copying unnecessary personal or operational information.
How do you protect access used for exchanges?
We use the permissions necessary for the agreed operations and determine who can administer access. Access data and technical information should not be exposed in error messages or reports. Retention and maintenance conditions are clarified according to the systems and data involved.
Where differences arise
between the same dates?
Show us the information that must be in agreement and the systems that use it. We can define the right source, frequency and checks before choosing the implementation.