What is Master Data?
Master data is data which rarely changes. Good examples of such data is a list of countries or postal codes. The opposite of master data is transaction data, which frequently changes. A good example of this is a sales order with a customer. In Blueriq, most of the profile belongs to the transaction data. It is not unusual though that you also have to handle master data as well. This how-to article helps you with the choices to make when modeling with master data.
Relevant Concepts in Blueriq
The following concepts are relevant:
| Element | How can you model Master Data with it |
|---|---|
| Value lists | Each value of the Master Data is entered in studio as possible value of the value list. You can place the value list on an attribute and the end user can select a possible value. |
| External Value lists | You can create a piece of code that is determining the possible values of a value list for you. How the piece of code does that is entirely up to you. You can place the external value list on an attribute and the end user can select a possible value. |
| Each value (or set of values) of the Master Data is entered in studio as a static instance. You then model a Container type: AQ_InstanceLinker, Container type: AQ_InstanceList, or a repeat expression to let the end user select a possible value (instance). | |
| Service call type: AQ_CsvConnectivityService | You store the master data in a CSV file outside Blueriq. Using this service, you load the data into the session as instances, one instance per row. You then model a Container type: AQ_InstanceLinker, Container type: AQ_InstanceList, or a repeat expression to let the end user select a possible value (instance). |
| Data rule | You store the master data in a CSV file outside Blueriq. Using the data rule, you load the data that matches your rule into the session as instances, one instance per row. You then model a Container type: AQ_InstanceLinker, Container type: AQ_InstanceList, or a repeat expression to let the end user select a possible value (instance). |
| Web Services | You model a Service call type: AQ_SoapServiceClient or Service call type: AQ_RestServiceClient to call an external web service that supplies the master data. The data enters the profile as instances. You then model a Container type: AQ_InstanceLinker, Container type: AQ_InstanceList, or a repeat expression to let the end user select a possible value (instance). |
How to choose
The above methods all have different characteristics, and based on your specific situation you want to choose the variant that matches your situation the best. Below we explain different characteristics and categorize each concept.
Who is the owner of the data?
Your project might own the data itself, such as product names. The data might also be owned by an external party, such as postal codes that are owned by the government. If the ownership lies somewhere else, then also the maintenance of the data should be handled there.
| You are owner | You are not owner |
|---|---|
| Value lists | External Value lists |
| Static instance | Web Services |
| Service call type: AQ_CsvConnectivityService | Service call type: AQ_CsvConnectivityService |
| Data rule | Data rule |
If you own the data, then you usually choose a concept that is easy to implement and to maintain yourself, such as a Value lists. You can choose Service call type: AQ_CsvConnectivityService and Data rule in both cases, irrespective if you are the owner or not.
Changeability of the data
How often does the Master data change? Is this once every several years (e.g., a new country comes into existence) or more often (e.g., an updated product catalogue). If the master data changes often, then changes have to be performed quickly as well without downtime.
| Traverse DTAP | Server Restart | Live Update |
|---|---|---|
| Value lists | External Value lists | Web Services |
| Static instance | ||
| Service call type: AQ_CsvConnectivityService | ||
| Data rule |
Value lists and static instance are part of your model. As your model has changed, customers usually require a new traversal of the DTAP street. The External Value lists is loaded into memory when starting the server. So this can be updated during a maintenance window.
Web Services and external Value lists can retrieve their value from some external source, of which the updates you do not control. You have to take these changes into account when modeling the application. You should always have a default fallback option in case an unexpected value is retrieved. If having such a fallback option is not feasible in the business context of the application, then a different option should be chosen.
Size of the data
Depending on how many entries the master data has, different methods are preferable.
| Small (<=50) | Medium (50-250) | Large (>=250) |
|---|---|---|
| Value lists | Service call type: AQ_CsvConnectivityService | External Value lists |
| Static instance | Data rule | |
| Web Services |
The chosen ranges for Small, Medium and Large are a rule of thumb and should be evaluated on a case-by-case base.
When the size is small, then you can easily create and maintain the data inside your model. When the numbers increase, you usually want to place the maintenance outside your application. The Service call type: AQ_CsvConnectivityService, Data rule and Web Services create instances in your profile for each possible value. With a large number of values this may lead to performance problems (think of long running COLLECT statements). For large numbers we advice to use External Value lists. Such a long value list can be easily searched by the end user using Valuelistsearch Presentation style.
Overview
Content Tools