Saving cost and company resources by decommissioning legacy applications sounds tempting. but how simple is it to execute the plan? Will application decommissioning cause a lot of complex manual work and are there tools out there to help with the project?
The latter question has an obvious answer. Yes, there are dozens of extract, transform and load (ETL) tools out there that can help decommission legacy applications. As a member of the OpenText family I was wondering what options we have “in-house”. Hence this blog post where I’ll test how OpenText™ InfoFusion Integration Center (OTIC) can be used to automate decommissioning legacy HR applications to OpenText™ InfoArchive (IA).
My sample legacy HR application is running on MySQL database and contains hundreds of thousands of records. The simplified decommissioning plan would contain the following 4 steps:
- Extract data model
- Extract application data
- Ingest data
- Configure InfoArchive search forms for the application
Step 1 – Extract data model
Before ingesting the legacy application data to InfoArchive you’ll need to create a metadata file describing the schema, tables, columns and data types used in the legacy application. This information helps IA to check the legacy data upon ingestion, helps developers configure the search forms etc.
You should always automate the metadata.xml file creation. Remember that there will be numerous iterations of the application export and the last thing you want to do is write and edit long XML files by hand. Luckily all of today’s databases contain some system tables that describe the application specific tables and columns.
We’ll therefore start in InfoFusion Integration Center by creating a Table that maps to the INFORMATION_SCHEMA.TABLES table in MySQL. In doing this we now have a list of all tables that belong to our application.
Similar to the above example, another table can be defined for INFORMATION_SCHEMA.COLUMNS. The Columns view will provide us with column names and data types for the IA metadata definition.
We shall be creating a metadata.xml document so let’s use an existing sample file or a schema file to configure an XML document object in OTIC. It will help in mapping the schema tables and columns to the target XML file. Once you import the file the XML Document object will automatically parse it and create the XML tree view and list all elements.
The data model tables and XML document are all we need to create the metadata.xml file for the legacy HR application. How can you do this in OTIC? OTIC uses so called Modules to “configure” a script that maps the source data onto the result format.
Side note: I couldn’t resist using the word “configure” in the previous sentence since it best expresses the way that Module Script editor guides you through the script creation. Instead of learning (yet another) programming or scripting language you’ll only need to right click and select data processing commands from the context menu. Dialog boxes will guide you when entering command parameters so you can be sure that your script will work immediately. Can you see now why I call it “configuration”?
You can encapsulate further modules in your main module to improve readability and enable reusability. I have created a “column type mapping” module to map MySQL datatypes onto IA supported data types.
After you’ve completed the module “configuration” then you can run it directly from the module editor or pass it for scheduled execution to the InfoFusion Integration Center platform. Our first step (and probably the most challenging one) in the application decommissioning has been successfully completed.
Step 2 – Extract the data
With the data model exercise behind us it will be fairly easy to generate a table object based on an existing table in the underlying legacy database application. As in the metadata step above we’ll need to define an XML schema describing the target export format. Having source and target you can start configuring a module that will read the source table and map it to the target XML format. You’ve got your XML data extracted in the required format with just a few clicks. Repeat the same sequence of steps for all remaining tables in the legacy application.
Step 3 – Ingest the data
Ingestion and InfoArchive (IA) configuration are no different to what you’d be doing with any source data, including data generated by the out-of-the-box IA connectors. All you need to do to ingest the data is to create a main application folder and put the metadata.xml file together with all XML data files into a subfolder called “tables”. Then just start the IA script to ingest the application and its data into InfoArchive. Step 3 is quickly completed and your legacy application data is now safely stored in OpenText InfoArchive.
Step 4 – Configure InfoArchive search forms
Your business users will need access to the data in InfoArchive (if they don’t need it why bother to decommission the app at all?). So let’s configure a few search forms in IA for them. IA forms can be easily built using the search form designer. Specify your search fields and list your search result columns and your business users will again have a view of their data.
Since we’ve archived multiple related tables we’ll need to configure the so called “nested searches” to enable the IA users to comfortably browse the underlying data and its relationships. With the main search forms configured your mission is completed.
It was fairly simple to use OpenText InfoFusion as the ETL tool for the application decommissioning. Even this first OTIC project created a lot of reusable assets (like the data type mapping module) that would simplify decommissioning projects going forward. Any subsequent application decommissioning project would be easier to accomplish since many of the ETL modules could be reused.
It took 4 simple steps to decommission a legacy HR application. Now that we have the application data in InfoArchive we can shut down the legacy HR application, remove the VMs, free up the space in the data center and focus on solving the new requirements from the business departments rather than just “keeping the lights on”.