When developing schemas, it helps to identify all of the necessary distinguished fields before deploying the solution into production. Making changes to a deployed schema can introduce un-needed complexity and pain if used across multiple projects.
Unlike promoted fields* however, it can be difficult to identify all of the necessary distinguished fields before deploying the solution (the business will always have a new requirement that needs you to subscribe to the one field you haven’t distinguished following the latest schema refresh…)
To help me identify distinguished fields I use the unique/constant rule:
- Unique = unsuitable. Unique fields will always contain data that is likely to change with each message instance (e.g. an order reference, invoice reference delivery date) or data that may change on a frequent basis (e.g. order date, delivery date) – It is highly unlikely that you will be required to subscribe to fields that change with each message instance and if you do, ‘why?’ should start to crop up in conversations with co-workers!
- Constant = suitable. Constant fields will always contain similar data (e.g. trading partner id, party name, routing id etc.), or data that could be considered as an enumeration (e.g. we are using a ‘message status’ field to identify how far through our core B2B process the message is, the statuses can be any one of MAPPING_COMPLETE, CONFIGURATION_COMPLETE or VALIDATION_COMPLETE).
The image above is a screenshot of version 2 of our core order message showing distinguished (constant) elements and attributes. Fields that are unique (message tracking guid, message guid, original message reference and source filename) are not promoted.
* In my experience, promoted fields are usually identified during the [orchestration] development phase.