Around Products
GetAllProducts
⚠️ DEPRECATED
This API route is very costly, resource-wise, for the ByMe platform, especially at scale. We advise against building a mission-critical component on it. This is closely related to our previous statement about what the ByMe platform is not: a primary storage.
Optimize Products
- Free tags set on products are used for the search engine within the 3D planner application and should not be used for other purposes.
- Debug information or additional information stored in the "clientMetaData".
Product attribute should be reduced to the minimum because it is loaded by the planner which does not need it, introducing performance overhead. Storing significant amounts of data in this attribute is usually the sign that the ByMe platform is improperly used. This data should be stored in the customer information systems only, and only what is directly useful to the planner should be published to the ByMe platform. - Avoid unused parameters in the products: each are stored with each of the (tens of thousands to millions of) projects. The impact would be global to the platform as well as impacting negatively the load and save time of each and every objects and projects.
Proper Use of Staging and Main Environments
Only applies to customers leveraging staging and main environments.
- Never deliver a new object in the main environment. It is currently allowed but as it can lead to inconsistent states after staging-to-main synchronization. It will be forbidden in the future. Every product creation should be performed in the staging environment.
- Avoid updating product information directly in the main environment. If it is necessary in the chosen RMS design, the modification should also be done on staging simultaneously.
- Updating product information in the main environment should be done only on commercial information (descriptions, images, prices...). Any modification regarding assemblies, product parameter should be done in staging and publish in main to ensure data validation and integrity. Indeed, publishing an object without considering properly all the objects it can be linked to, could lead to data inconsistency.
Product Identification: Avoid Functional Identifiers
Using UUIDs as product identifiers has many upsides, especially enabling product updates while retaining the previous product version to open past projects, which would be impossible if both were identified by their identical reference.
State Synchronization
A state-of-the-art data architecture should be put in place in order to maintain the publishing state between the Range Management System and the ByMe platform.
From our experience, the Range Management System should manage the following topics:
Perform Range Management with your Own Words
Manage information according to your "business vocabulary" like business units, retail units, design names, attribute names (article number vs reference vs EAN etc.). Especially when these do not have an one-to-one mapping to the ByMe concepts.
The RMS is the Rosetta Stone
RMS should manage a "Mapping table" between customer's object identification schemes (internal database ids or item numbers) and ByMe object ids (UUIDs). Do not store this information in the ByMe platform.
Store as well a "variants information" that enable to support several products in ByMe that correspond to a single article number (or reference) in the source system.
The following diagram illustrates the high-level principles of a possible RMS architecture leveraging the principles listed above. Obviously, this architecture has to be adapted to customer particularities.
| Description | |
|---|---|
| 1 | Customer Database(s) that holds the customers users with their technical ids and personal information. |
| 2 | Database(s) that contains information needed for configurators (including 3D configurators). If not existing it has to be built by the customer. Assembly format (.BMA files) helps to describe position in 3D between products and can be used if not existing in the customer information system. The structure of the data is probably not matching the ByMe platform. |
| 3 | Extract Transform Load: Please refer to https://en.wikipedia.org/wiki/Extract,_transform,_load. It is the key component of the RMS. |
| 4 | Mapping Table: The place to store all the data needed to map objects (1 to many) between customer information system and ByMe platform and that makes the ETL the most efficient. |
| 5 | Staging ByMe Users Database: It should contain customer's employees or people having its delegation and who are in charge of maintaining the range and/or perform quality assurance. |
| 6 | Staging ByMe Content Database: Stores all the metadata related to ByMe objects that model the range. |
| 7 | Main ByMe User's Database: It holds the link between users Id and projects. It should contain consumers technical Ids with an one to one mapping with customer users database(s). |
| 8 | Main ByMe Content Database: Stores all the metadata related to ByMe objects that model the range. |
In any case we advise against storing the publishing state and mapping data in the ByMe platform.
Publish Increments
In most range maintenance scenarios, not all articles and products are updated at the same time. We strongly advise to perform an impact analysis on the changes and only publish the identified changes to the ByMe platform. Republishing a large range would have an adverse effect on the Range Management cycle times, as well as on the platform itself.
As a corollary, do not have the RMS perform massive GETs on the ByMe API in order to figure out what to publish.
Product Retro Compatibility
Some updates to the product object should be avoided, for customers wishing to offer the possibility to re-open past projects that include this product. Hence, this does not apply to customers working on "throw-away projects".
When such non-retro compatible updates on a product are needed ("No" in the following table), we recommend to create a new ByMe product to represent the new product version; in all other cases ("Yes"), updating the existing product would retain the capability to open past projects.
The following table specifies when it is not necessary to create a new ByMe product:
On Product level:
| Change | Retro compatible |
|---|---|
| Add new parameter | Yes |
| Remove existing parameter | No |
| Rename existing parameter | No |
| Change parameter default value on TOP | Yes |
| Change parameter default value on SUB | Yes |
| Add value(s) on a parameter | Yes |
| Remove value(s) on a parameter | No |
| Change visibility/editability on a parameter | Yes |
| Change behavior/classification/free tags | Yes |
| Change type | No |
| Change commercial data (desc, thumbnail,..) | Yes |
On BM3 level:
| Change | Retro compatible |
|---|---|
| Geometry | Yes if identical box |
| Add new publication | Yes |
| Remove existing publication | No |
| Rename existing publication | No |
On BMA level:
| Change | Retro compatible |
|---|---|
| Add new parameter | Yes |
| Remove existing parameter | No (except if not referenced) |
| Rename existing parameter | No |
| Update overload | No |
| Update component list | No |
| Update relation | No |
| Update internal data (cutout, anchor points,..) | No |