In part two of the new ALM Explained series, we discussed the best practices for testing and validating changes prior to deploying them to production models.
However, we also know that testing protocols are not always followed, especially if the change is an emergency patch, and sometimes, the synchronization can cause issues in the production model. There is a defined best practice for “hot fixes”.
If the change needs to be reversed, see part two section on ‘reverting a revision’. However, the worst-case scenario is when a synchronize causes users’ data to be removed, and, in this case, just reverting to the previous revision is not going to restore the data (because data never moves from development to production).
The following are some of the most common examples of how stored data might be overwritten following a synchronization:
The first four items are largely self-explanatory, but let's dive deeper into the last one, as this is probably the most common reason for data loss—and the least understood.
Before we look at how data loss occurs, let’s recap the concept of production lists.
Structural information refers to the configuration of the model:
These are elements that cannot be edited in deployed mode; there is no expectation that end users will need to amend these structures.
Production information generally refers to the operational data within the model; for the most part, this will be data entered by users and the users list. When it comes to lists, there are times when we expect that the list's members will need to be amended within a deployed model:
Setting the list as production data prior to setup or a synchronization allows the list members to be added, deleted, or amended within the production model in deployed mode. When the synchronization takes place, only the structural information is transferred; production data never moves from development to production.
For information on Production Lists, see here.
One of the most common causes of loss of data in a deployed model is changing the list setting from production data back to structural. We need to look in detail at what is actually happening under the covers to explain why.
Each list member has an associated internal id. If the list is set to structural, when the initial synchronization takes place, the lists are different, but the list members are "effectively" the same and have the same ids. For simplicity, I have assumed the id is four alphanumeric characters; in reality, it is 12 digits.
When a new member is added to the list in development, on the next synchronization, this member is added to the list in the production model. Note that no data values are transferred across, as the data remains as production data.
Let’s assume that P1 Products is now set to production data. On the next synchronization, the link between the two lists is broken, but to maintain integrity, the list members and associated data are retained.
When a new item is added into the development model, because the list is production data, this member is not transferred over on the synchronization.
Users are able to add items into the list in production, and these items are not added to the development model.
Now, let’s assume that the list is re-set back to structural. This is where the problem occurs. The production list members are effectively deleted and re-added, they are given new ids, and any data associated with the list members is deleted.
Hopefully, this process will not be needed, but just in case the worst happens, the following steps are a way back. The steps below are able to correct basic issues, such as simple structural changes, or where formulas are added to 'data' line items. Depending on the level of complexity, it may not be possible to restore the data, so it is important to follow the correct testing protocols as outlined in part two of the new ALM Explained series.
As part one explained, models are connected through revision tags, and deployed mode ensures that the compatibility is maintained. This process does mean breaking the golden rule of ALM (‘never take the model out of deployed mode’), but this is an exception. Follow the process below, do not deviate, and you can restore the data lost through an erroneous change while maintaining compatibility.
Remember, “with great power comes great responsibility”. Follow the rules, test thoroughly, and adhere to best practices to ensure a seamless Application Lifecycle Management process. I hope this three-part series has helped you develop a deeper understanding of the fundamental concepts of Application Lifecycle Management so that you can fully utilize the functionality and avoid any pitfalls.