Migrate from ODF to ODF 2

info

You don't need to migrate existing BPs from ODF to ODF2 if you haven't faced any ODF limitations impacting BP quality. The Product supports the execution of BPs created on both versions of ODF.

Why migrate from ODF to ODF 2?

In earlier versions of the WorkFusion platform, the ODF framework was the standard for implementing AI Agents. However, it has some limitations associated with its design.

• Several AI Agents in the same environment use a single transaction table. With the increasing number of AI Agents and the substantial amount of data produced by an AI Agent, it makes the data search less effective, access to data slower, and the entire workflow less productive. In ODF, the data model flexibility was provided via storing data as JSON, though in an unstructured form. If you need to constantly update data related to your transaction, to search, or to filter it, these processes aren't quite efficient. ODF 2 solves the problem by abandoning the _odf_transactions Data Store in favor of flexibility in managing a data schema. For more details, refer to Data Model management.
• In ODF, development is mainly in Java, but you still have to create Bot Tasks using the WebHarvest markup for Business Processes (BP). With the new framework, you don't need to learn an additional technology due to the automatic generation of WebHarvest in Bot Tasks.
• For the ODF framework, you can use one transaction in the context of one Business Process only. ODF 2 enables you to apply the architectural techniques of decomposition, allowing the development of AI Agents in a more flexible manner and with better reusability of components if you have several Business Processes that make up a single AI Agent.
• With ODF 2, it's much more convenient when several Business Processes use the same transaction. To implement this, an archetype creates a project template based on a new technical design.
• ODF 2 also contains a library with standard Bot Tasks you can reuse from project to project, while ODF doesn't offer out-of-the-box code solving similar technical problems.
• Now, you have a good solution for object-relational mapping. WorkFusion integrated the OrmLite framework, thus enabling sensitive working with Data Stores treated not as tables in a database but as actual Data Stores considering specific requirements the platform imposes on them.
• ODF 2 offers an efficient strategy of importing Data Stores.
• WorkFusion continuously contributes to a special library of custom OOTB components where developers can share best practices.

Summing up, ODF 2 is the next level of well-thought framework to support implementation teams in building even more complex, large but testable and maintainable solutions.

General migration procedure

The intruction describes a simpler, straightforward way to migrate by creating a separate Maven project and moving or reimplementing code.

caution

Mind that the approach does not work for large long-lasting automations as, in most cases, a team can’t freeze scope development and focus on migration only. Also, the procedure interferes with development practices. Specifically, the changelog history of all the source code can be lost.

The only way is to switch an original Maven project and migrate bot step by bot step, starting from one part of your Business Process being in ODF and the other—in ODF 2 and then gradually moving the entire Business Process to ODF 2. The steps below are similar at the level of a single Bot Task. The general rule is to make incremental changes in the branch and merge as soon as possible to have a working project at the end of each iteration.

1. Prepare two versions of the Maven project:
   • Ensure the original ODF Maven project works. It should be built in IDE and deployed to Control Tower, with all its Business Processes working in Control Tower.
   • Generate a new blueprint ODF 2 Maven project from the Simple Archetype. The new implementation code is kept separate from the old one. Ensure the newly generated project is built in IDE, and its bundle is deployed to Control Tower.
2. Analyze Business Objects you have in the original project. Work on building Entity objects using ORMLite in the core module (src/main/java/com/example/model) and modify an initial Liquibase migration to create a Data Store schema corresponding to your objects in the package module (src/main/resources/datastore/migrations).
   • To avoid creating unnecessary initial migration steps, in your development environment, erase Data Stores created by your first AI Agent deployment.
3. Rewrite Bot Tasks to Java. In ODF 2, you don’t have to type any lines of code in WebHarvest or Groovy manually.
   • Use new out-of-the-box platform APIs to work with Data Stores, S3, OCR, and others.
4. Move all configuration points to the special configuration Data Store provided by ODF 2 and rework all usages.
5. Re-use the code as is:
   • If you have implemented RPA in Java using PageObjects or an RPA class directly, you can copy all packages and classes to the ODF 2 project. Make sure you bootstrap your RPA initializers in new ODF 2-style Java-based Bot Tasks.
   • You can copy as is all common utility libraries, such as converters, validators, wrappers for third-party libraries, to the ODF 2 project.
6. Deploy new Bot Tasks to Control Tower once. To rebuild a Business Processes with new ODF 2-based Bot Tasks, drag and drop them into proper places within the BP.
   • Export the modified Business Process to zip archives and put it back to Bundle resources in src/main/resources/business-process.
7. Add automated tests for your AI Agent-specific source code:
   • Java unit tests with mocks
   • Bot Task unit tests simulating each task input
   • Business Process integration tests simulating each Business Process input