Follow

ODX Server: Benefits and Considerations

Introduction

This article explains the benefits of using an ODX Server as opposed to a Business Unit, when ingesting data, particularly regarding the implementation of new solutions. For existing solutions, there is no reason why these cannot continue to rely on the Business Unit functionality, and in some specific scenarios this might be advisable for the time being. However, in many cases migrating from a Business Unit to an ODX Server can offer benefits, and give way to opportunities, which are covered below.

What are the benefits of using ODX Server?

  • Data Sources 
    • A growing list of providers for various data sources
  • Reaping the performance benefits of Azure Data Factory (ADF) 
    • Access to ADF data sources
    • When using ODX server, ADF can be leveraged for transferring source data to storage, and to a data warehouse. The data pipeline architecture behind ADF offers improved performance and is highly scalable, meaning that transfer times can be rapidly reduced.
    • ODX can also be installed on-premise and use on-premise data sources. This is possible because of Self-hosted Integration Runtime, which allows the ADF engine to access and transfer on-premise data, and allows TX to leverage ADF pipeline architecture, while the firewall remains in place as-is.
  • Promoting the Data Lake Concept and Infrastructure 
    • ODX Server does not support the transformation of data or provide the ability to override original field names during ingestion of data in the ODX server. This promotes the data lake concept by ensuring that the data is initially ingested and stored in a raw format. Data scientists often request raw data, and initially storing data in its raw form also allows for greater insight into data lineage (i.e. what is the original source of the data and how is it later being transformed). It also makes the transfer of data from source to storage faster due to fewer transformations. However, it is worth noting that it is possible to “query tables” using SQL code when setting up data sources, and thereby apply transformations and renaming of fields – although in general this is not considered best practice.
    • ODX Server allows for data storage within the Azure Data Lake infrastructure, which cannot be achieved when using a Business Unit.
    • The ODX Server creates multiple versions of source data, which are stored after each scheduled transfer task (e.g. one version per day). TX projects pointing to the ODX server automatically use the latest version of data. It is possible to configure and schedule a storage management task to delete, and manage, old versions of data to free up storage. This archival process is driven by inexpensive storage, and lends itself to the data lake concept. It also allows for the creation of backup files which may be used for recovery.
  • ODX is built for handling sources with a lot of tables 
    • Selection of data is quick, as it is simple to dynamically choose which tables and columns from data source are brought in (e.g. all tables from a particular schema, or tables with names containing a particular term).
    • Business unit focuses on single selection of tables and fields, whereas ODX focuses on bulk load and bulk selection of tables and fields at data source level. This means that if a new table or field is added in your data source, it can automatically be added and stored in the ODX server, based on scheduled data source synchronization and transfer tasks.
  • ODX server improves team development and supports the server-client experience 
    • TimeXtender does not have to be installed on the ODX Server. Developers can install TimeXtender on their own machines, and load source data into storage through the ODX server transfer task, without ingesting the data onto the developer machine. The data is transferred directly to the ODX destination server.
    • This provides much more server-client like experience, as opposed to a desktop-client experience. Using ODX server in combination with direct read on data warehouses, means the TimeXtender application becomes purely an orchestration tool, transferring data without involving the application server.
  • All new developed functionality is going to be done on ODX server
    • In future releases of TimeXtender, Business Units will be phased out.
    • Additional data source providers will not be added to Business Units.
    • It will be possible to continue using Business Units using prior releases of TX. There will be long-term support for version 20.10+, and some features will possibly be back-ported as necessary. However, if you would like to upgrade to the latest version of TimeXtender, then Business Units would have to be migrated to the ODX server.

Considerations when migrating from Business Unit to ODX Server

Below are a few specific cases where it might be advisable to continue using Business Unit functionality for the time being:

  • Solutions containing NAV and AX data sources. Some functionalities within these Business Unit “adapter” data sources are not yet available in ODX.
  • Customers that have multiple environments for their source systems and wish to align promotes within source system and promotes in their data estate. Currently, a TimeXtender project only loads data from one ODX server, which typically sources data from Production systems.
  • If a customer relies on a Business Unit with substantial transformation logic, transferring from this Business Unit to the ODX Server will currently require manually moving this transformation logic to the DSA layer, as ODX does not support transformations (apart from Query Tables).
Was this article helpful?
1 out of 1 found this helpful

0 Comments

Article is closed for comments.