Tech Note: Oracle BAM – Migration Procedures Supported Version ...

Tech Note: Oracle BAM – Migration Procedures Supported Version: Oracle BAM 10.1.3 (migration steps applicable for earlier release) Objectives: • This document briefly explains the steps to migrate from one BAM platform to another. • User can use the same steps to take a back up of your BAM objects, for transfer to another system (development to test etc). • Use the same steps below to export any components required, and sent to Oracle tech support for problem resolution. Prerequisites • Understanding of BAM environment. • See product release notes and install doc. Description To prepare for migration, it is required to follow the below steps. All BAM components can be exported to an XML format file. Do not attempt to modify the contents of these XML files. There is no dependency on exporting the BAM components, but to import the BAM components back into BAM environment, there “could” be some dependencies. The dependency could vary depending on your project components. For many cases, the export and import feature should take less than 1 hr. (some data objects with large data could take a lot of time). Normally all file sizes (except for data objects) are small. Data objects exported can take a lot of disk space (large file size) depending on the number of data rows. Do not attempt to export/ import components directly into BAM repository or Oracle database. All BAM services should be started before use of any export or import commands. IMPORTANT: Take a database level dump (export) for the Oracle BAM user schemas before proceeding with any migration on the ‘same’ box. This will serve as alternate resource if need be. Database dumps can be taken for orabam & orasagent schemas (or your Oracle BAM and EnterpriseLink schemas). See: http://orafaq.com/faqiexp.htm#WHATIS Reason for Migration It is highly recommended to migrate to the latest version of the software for many reasons, such as bug fixes, improved features, performance etc. Warning: Please try first all the steps on development system. iCommand iCommand is a BAM software provided utility to assist in exporting and importing various BAM components and meta-data. Type- “icommand” on DOS prompt to provide

TechNote_BAM_Migration.doc Page 1 of 5 Oct 16, 06 (version 10.1.3) Document version (4) Oracle confidential, All rights reserved

Tech Note: Oracle BAM – Migration Procedures a full self help descriptive usage. Follow the steps given in iCommand help description to provide required command line parameters. Example to export: [italic = variable parts] iCommand cmd=export name=myComponent type=dataobject file=myFile.xml Example to import: [italic = variable parts] iCommand cmd=import file=myFile.xml Components to migrate (export) Administrator Components: EMS Type: Not recommended to migrate in most of the cases, since these are default settings for class path for various message source types. If you re using some specific class path settings, it is OK to export these meta-data. Usage: icommand cmd=export type=emstype name=”myEMS” file=myEMSfile.xml Users & Roles: Export the user names and roles if needed, using the same icommand utility structure as given above. If you are using special LDAP settings, make sure to save those settings. Plans: Export the Enterprise Link plans that are of interest for your project. Usage: icommand cmd=export type=plan name=”PlanName” file=myPlan.xml Architect Components: EMS Source: Export the project message source that are of interest for your project. Usage: icommand cmd=export type=ems name=”theName” file=myEMSsource.xml External Data Objects: Export the project external data objects that are of interest for your project. Usage: icommand cmd=export type=eds name=”/Folder/EDSName” file=myEDSdata.xml Note – when the External Data Object is exported the contents are exported along with the definition, but when the external data objects are imported, the contents will be ignored. Folder name may or may not be required depending on your project organization. Data Objects: Export the project data objects that are of interest for your project. Usage: icommand cmd=export type=dataobject name=”/Folder/myDataObject” file=myData.xml

TechNote_BAM_Migration.doc Page 2 of 5 Oct 16, 06 (version 10.1.3) Document version (4) Oracle confidential, All rights reserved

Tech Note: Oracle BAM – Migration Procedures Note – when the Data Object is exported, the file size could vary depending on the data set in the object. It is possible that the exported file could be of very larger size, if the data object is very large number of rows (in 10s of 1000s). ActiveStudio Components: Reports (Shared & My Reports) Export the project reports(s) that are of interest for your project. Usage: icommand cmd=export type=reports name=”/XX/myReport” file=myReport.xml Note – when the report is exported, you should provide the correct path or folder name (XX) as given above. ICommand help usage provided the syntax and format for the complete folder path for both “shared folders’ and “myReports”. Images: Copy all the images used by the reports and their encrypted formats from the source server to the destination server. Alerts: Export the project alerts(s) that are of interest for your project. Alerts are referred to as “rules” in the export command. Usage: icommand cmd=export type=rule name=”/private:domain\userid/Rule/myAlert” file=myAlert.xml Non BAM components (or dependencies): Export all other non-BAM components, other meta-directory or data or dependencies that are required to complete your project. Example: Tables used by External Data Object, LDAP files, windows user names, any configuration files or external dependencies etc. Verification Verify that the exported files are not zero file size, and contains some xml text. Do not edit or modify these exported files or any contents or parts of XML data. Uninstalling BAM: Uninstall the BAM components (EnterpriseLink and BAM) using Windows Control Panel. After uninstalling, clean up old directories (or rename the directories to oldXX). Uninstall dotNet and ODAC client from Windows Control panel. Preparing for New Install: Verify OS, Patch, DB version. Verify that you have the correct operating system, patch levels, database versions as given in the install document for the BAM release. Read the release notes for all information about the particular BAM release. Install & Verify: Install new version of the BAM software as given in the install document. Verify that the new installed software is complete. Open BAM console, and TechNote_BAM_Migration.doc Page 3 of 5 Oct 16, 06 (version 10.1.3) Document version (4) Oracle confidential, All rights reserved

Tech Note: Oracle BAM – Migration Procedures check the Architect window, sample dataobjects. Verify new install version on the BAM console, “About’ button. Importing Components: Task after installing new version: Complete the following tasks as 1st steps, before moving to the next sections. Set email server in the BAM console, Administrator screen.. Apply any configurations (example: external tables, log levels, ldap connection etc). Import or create the users login and roles as required. If importing user names & roles using exported files, use the icommand utility to do so. Example: icommand cmd=import file=myFile.xml Importing files back: The order of importing the files is dependent on the ‘components’ that are imported. In some cases (if you are overwriting any existing environment), it may be required to delete the existing component or definition. Use icommand delete option or open the console and delete the component. Note- after deleting the component, there is no un-do operation. The order of importing the files back into the BAM environment is given below (as an example). If the import command fails, watch the error message carefully either for an “already existing components” (in which case you have to delete the old component) or missing “dependency object” (in which case you have to import the dependent object first). External Data Source: If necessary, create any required external database tables and verify their completeness. Import the EDS files and open the EDS definition in BAM console-Architect. Import the data object files for any external data objects. Verify that the EDS components are imported, and connecting to the external source by viewing the contents of the external data objects in Architect. Modify the source definition (server name, user name etc), if required. External Message Source: Import the external message source, and verify or modify the connection details if required. Example: server name, jndi properties, etc. Data Objects: Import the data objects, open Architect window and verify. Import the files for any data objects that are used in lookup fields first. Plans: Import the plan definitions. Open DesignStudio and verify plans are imported properly. Open BAM console –Administrator and verify plan monitoring settings, if any (set to required run conditions as needed by your project). If plans contain, any meta view or sql select, it is advised to recreate these steps again in the imported environment (this is much easier than following steps to export plans with sql statement and db

TechNote_BAM_Migration.doc Page 4 of 5 Oct 16, 06 (version 10.1.3) Document version (4) Oracle confidential, All rights reserved

Tech Note: Oracle BAM – Migration Procedures information). Alternately, consider moving away from plans using metaview by alternate design approaches (such as triggers/ db streams etc) Reports: Import the BAM reports, open ActiveStudio window and verify in both “Shared Reports” and “My Reports” directory structure. Import any reports that are used as targets for drill across in other reports first. Actionable Buttons in Reports: If the reports have any actionable buttons or links, then you need to verify (and modify if needed), that the new migrated reports will point to the required URLs as required. Images: Copy all the images used by the reports and their encrypted formats from the source server to the destination server. Alerts: Import the alert rules, open Active Studio window and verify. Note that Alerts exported contain reference to user id and machine id, if these donot match in the imported environment, you have to recreate the alert definition manually. Alerts calling webservices: If any alerts call external webservices, after migration, verify (and modify if needed) that the migrated alerts points to the end URL as required. Importing non-BAM components: All other external components such as LDAP configurations, windows user name, data base sources, need to be imported and set correctly. Summary: 1. Steps to migrate from one platform (or environment) to another. 2. Detailed steps to export all BAM artifacts (metadata/objects) using iCommand. 3. Detailed steps and dependencies to import the components into BAM system. Questions & Clarifications: If you have any comments or need additional information, please communicate through the Oracle BAM forum at: http://forums.oracle.com/forums/forum.jspa?forumID=252

TechNote_BAM_Migration.doc Page 5 of 5 Oct 16, 06 (version 10.1.3) Document version (4) Oracle confidential, All rights reserved