OTM 6.2 Upgrade

Using the….

Janice Gottlieb

Tennin Systems, Inc.

Janice@TenninSystems.com 412-927-2820

© 2012 Tennin Systems, Inc.

All Rights Reserved

Background Independent IT consultant and partner in Tennin Systems, Inc

Over 20 years' experience architecting and developing enterprise systems in the financial services and manufacturing industries.

5-1/2 years experience in OTM Integration – Java Programs/Web Services Technical Support Functional Support Overall OTM Administration

Unrepentant Pittsburgh Fan Go Pens! Go Steelers! Go Bucs!

Once upon a time

in a land far, far away,

there was a company

that needed an OTM

Upgrade…

... and the Wizard

waved his magic wand

and in what seemed

like a blink of an eye,

OTM was magically

upgraded.

The Fairy tale

The Real Story

And after months

of hard work,

we were able to

reduce the install

time by 75%. The

install time was

reduced from

over 24 hours

to less than 6

hours. The team

cheered, and the

business was very

happy that they

could resume

shipping.

THE END.

Upgrade Scope Version: OTM 5.5 CU5 RU4

Platform/OS: AIX 5.3

App Server: WebSphere Single App Server 4 Web Servers

Version OTM 6.2.3 4+ release upgrade,

including a major Version

Platform/OS: Linux RedHat 5.6

App Server: Weblogic

2 App Servers 2 Web Servers

All New Hardware

Project Scenario Hardware resource review by Mavenwire.

5.5 hardware would not handle the new functionality/future growth.

OTM upgrade was originally part of another OTM project/team.

Upgrade was later broken out into it’s own project. Short time-frame

as upgrade was a prerequisite to the other project.

Decision to add additional OTM expertise to ensure project success within time frame.

Assembling the Team

It takes a village…. OTM Technical Lead Developers/Programmers (Integration, testing tools) System Admin (AIX and Linux) DBA Network Admin (Load Balancing) Technical Architecture (Single Sign-On) OTM Business Lead Business/Technical Testers Business & Technical Management Support Oracle Support Partnered with Mavenwire (additional OTM expertise)

Archive and Purge

Clean it up The size of the database can effect the

length of the upgrade process.

Archive and Purge. Normally Keep 60 days transmissions, purged

down to 7. Orphaned Status Recs, Calendars, problem,

i_log, l_log detail, process_control, appointment Truncate empty partitions. Saved over 4 hours

If you are moving the database, its an opportunity to reorg.

Upgrade Major Steps

5.5 CU06 (Websphere/AIX)

6.2.2 (Weblogic/Linux)

6.2.3 Patch

Custom Migration 1

Bug Fix Patches

Custom Migration 2

The Shortest Distance between 2 points is a straight line….

…. Not always….

Staging the Upgrade

Straight line approach

Upgrade the code. Upgrade the database Repeat.

Have to start from scratch every practice run.

Coordination effort between team members.

Very long process.

Staged Approach

CU 06

6.2.2

6.2.3

Patches

DB

Staged Approach Advantages

Code can be upgraded first, independently of the database. If moving to new hardware, this part can be completely done

beforehand. Saved several hours.

Database upgrade can repeated over at any step to work out problems, timing. DB upgrade can be run from any server, as long as you are pointed at

the correct database. This may give you some options to stage the install even if you are not changing your hardware.

Less coordination. Teams can work independently, not having to wait for the other to finish.

Indexing to improve performance Invoice changes ran very, very long.

Significant structural changes to the Invoice tables.

Over 700,000 Invoices

Added index to INVOICE_SHIPMENT

(invoice_gid+lineitem_seq_no+shipment_gid+s_ship_unitgid+s_ship_unit_line_no+tracking_number)

Reduced Time by 3 hours.

Indexing to improve performance This hint was passed along by a colleague doing another

6.2 upgrade.

Convert orders process (new order movements in 6.2).

Can take a very long time depending on the number and complexity of the orders.

Disable the triggers on ORDER_RELEASE table and add parallel hint to the sql in the convert_orders package.

Reported a conversion time from hours to minutes.

Scripting the Process To reduce the time, automate the process as much as

possible.

All OTM configuration changes were scripted. Connection Pool, AcrRoleRole, LogicParameter,RuleSet, Scalability,

Caching

All custom/company specific changes were scripted. Screens, Menus, Agents, Packages, Triggers, OutXmlProfiles,

Milestone Monitor.

Used OTM scripts to assist with the custom update update_onecsv.sh

Partition Long Running Processes

Tender Transmission Partition Move 4 Parallel Processes

Gather Stats

4 Parallel Processes

Practice, Practice, Practice

The single most important thing you can do.

No surprises on the day of the upgrade

Practice Tips

Start with a copy of Production DB Clean-up Purge/Truncate

Keep a backup at each step. On disk if possible.

Lots of extra disk space

Keep the final copy for testing.

Results 17:00 Start

Shutdown OTM Shutdown all Integration Backup the DB

17:45 Run all OTM Scripts 5 hours

22:45 Restart all OTM Servers 23:00 Test/Verify OTM Basic Functions 24:00 Enable Integration/Load Balancer/Verify Change DNS for new servers 01:00 Complete

8 hours total

Questions