Application lifecycle management and environment lifecycle management

20 minutes

One key aspect of the table maps and customization of them is management of the changes. It’s important to know how to manage these different table maps. Moreover, knowing how to manage the version of these maps and the different changes that are made during the life of the dual-write integration is also imperative.

In Dataverse, concepts of version control and application lifecycle management (ALM) are through solutions. Therefore, it makes sense that dual-write maps are managed as Microsoft Power Apps solutions. This mechanism is for altering the packaging and maintaining various components of Dataverse. The entity maps, extensions, and customizations are solution aware, and they’re managed similarly to Dataverse. The phrase solution aware means that a component is a piece of the system that can be packaged and therefore imported and exported between environments and systems.

Extensibility options

The first step is to customize the out-of-the-box standard maps from the dual-write solution. In the Use key concepts and setup to integrate finance and operations apps with Microsoft Power Platform module, you learned how to install the orchestration solution and the core solution. Both solutions house the out-of-the-box maps that you can customize.

Table maps

Businesses will likely edit and change table maps. As they do so, certain properties for the mapping will change as well. Each table map has a publisher and a version, both of which you can change as the table maps are customized. Additionally, you can increment each table map in version. However, keep in mind that dual-write supports table mappings only between cross-company tables or company-specific tables from both sides. You can’t have a cross-company table mapped to a company-specific table; thinking about the integration key concept will inform you when you’re customizing these mappings. Each dual-write solution can contain one or more dual-write table maps.

Column mapping

Within the dual-write table mappings, you can also edit and set up the columns. You can add a new column by selecting Add mapping and then selecting an existing or custom column in the list. You can add System and Customer columns as well. You can customize the synchronization direction (unidirectional or bidirectional) and add transforms by selecting the map type.

Two types of transformations that you can select are:

Default - The default values are the values that are applied to the destination columns when no source column value is available.
Value map - Defines how values that are present in one table should be mapped to values in the other table.

For more information, see Customize table and column mappings.

These changes to Standard or New table mappings are saved as part of the dual-write core solution, specifically the Dual Write Entity Map repository as part of ALM. Additionally, you can create custom solutions for even more control over the versioning and life cycle management.

Filtering

A common question that’s asked during implementation of dual-write is about the filter capabilities and how to change them in finance and operations apps and customer engagement apps. Filtering capabilities can affect your dual-write integration, so it’s important to know about the options that are available to you.

Filters for dual-write in finance and operations apps are available for primitive data types and simple queries. These filters don’t support date-time data types, long strings, or containers and other complex columns that you might have.

The filter expressions in dual-write for finance and operations apps are evaluated and transformed into a SQL statement, where nulls are typically expected. However, null filters aren’t supported due to platform limitations for finance and operations apps; null is equal to data, and it’s not simply missing. For example, a filter on a data entity might be set to an empty string “ “. If the evaluation ends in an empty string, it will evaluate as true. However, if the evaluation is NULL, and the returned value is NULL, then it won’t evaluate as true.

For these cases, and for more complex filter situations, we recommend that you:

Try using a computed column, Boolean field, or other simplistic filter criterion that will return a more simplified dataset. Computed columns can specifically handle date ranges or other more complex scenarios at the entity level.
Make sure that the filtered data is mapped to correct fields and columns if the filtered data is important to transfer. This concept is important. For example, consider a scenario where you have a contact person that is used for a dual-write map, and you have a filter on the associated contact number but don’t have a physical map on the contact number column. In this case, edits on that filter will not be picked up by the dual-write integration because dual-write only tracks the fields that are mapped directly. As a result, you’ll need to ensure that the filtered column is part of the map. Make sure that you evaluate the business processes to ensure that the filtered columns that are a part of adding, removing, or updating data, are mapped as well.

Filters in Dataverse are different because they use OData filter expressions and are more simplistic than filters that are available in finance and operations apps. Only the standard filter operators that work directly against Table columns are supported in finance and operations apps.

For more information, see Filter results - Standard filter operators.

Environment lifecycle management

When you have a solution, whether it’s a custom or an extended standard solution, you can publish and import it into another environment. This option exists because, typically, a 1:1 ratio of environments exists for finance and operations apps and Dataverse.

For example, in finance and operations apps, you might have several development environments, a Test environment, a Stage environment, and a Production environment. As you develop new functionality for finance and operations apps, the solution will be published through packages to each environment for different purposes. In the test environment, you might have all users test the functionality and new features that have been developed. When the solution has been promoted to the stage environment, you might have little validation to do before pushing the changes to production, where people will use the new feature or customization.

A similar process exists for Dataverse. This process of moving development and changes from one environment to another is part of ELM and ALM.

Another aspect of ELM is updating the version of finance and operations apps or Dataverse, and even dual-write’s core solution, to get more features and functions released from Microsoft to enhance the daily use of the applications.

The promotion or movement of development from one environment to another, and the process of updating each environment for finance and operations apps and Dataverse, is known as the environment lifecycle management (ELM).

In Dataverse, this process resembles the process of publishing newer versions of solutions, whereas in finance and operations apps, this process resembles the process of promoting and applying custom code packages to environments. For dual-write, this process resembles the process of updating table maps based on the new solutions and business logic that are applied to both systems. Each process is needed to ensure that environments that are connected by dual-write are up to date, have the latest and best information for business users, and show updated versions of mappings for the integration.

For more information about dual-write, promoting solutions, and the life cycle management of dual-write, see Application lifecycle management.