Common properties
Since all entities in EVA are basically represented by a JSON data model, we try to be as consistent as possible in naming their properties. This results in you coming across some properties on a regular basis. In this document we talk about common properties and what they are meant to represent.
BackendIDs
These are extremely common. We have normal BackendID's, BackendSystemID's, ProductBackendID's and some more.
BackendID's are ID's that did not originate in EVA but in some third party system. We do however want these ID's to be known in EVA for matching and communication purposes.
Let's say you are importing a bunch of products from an external product information management system into EVA. During the import, you can specify the BackendSystemID, which should represent the external PIM system, and the BackendID, which should be the ID the product has in the external system.
After the import, EVA will generate its own ID for the products. Often referred to as either ID or EVA ID or any other form of ID that does not specifically identify itself as a BackendID.
Order Numbers
All orders in EVA are given a sequential numeric ID, unique only within the context of their region. Regions can be given prefix codes, typically “EUW”, “ASE” and “CUS”, but ultimately up to you to choose.
Upon the creation of an Order, this region code, suffixed with the Order ID, is stored as GlobalID on the order (e.g. ASE123).
Most Stencils and Services expose this and/or the region code. If missing, it's possible to add. Some custom integrations also expose them, which can also be added if missing.
Events do not yet expose the region code and Order ID.
You cannot call EVA services with this GlobalID, as each region services their own endpoint.\n\n For example: it'd be misleading to call GetOrder on ASE123 on the EUW region endpoint.
BackendID is not managed by us, so if a globally unique approach is of interest, it is recommended to develop outside of EVA.