Migrating Application Integration Data


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

WLI Doc Home \| Application Integration Topics \| Using Application Integration \| Previous Topic \| Next Topic \| Contents \| Index \| View as PDF

This section includes information on the following topics:

Overview

Application integration configuration data is stored in the same repository as data for business process management (BPM). Therefore, you can use the same tools to migrate application integration when migrating BPM data. However, there are some special considerations for migrating application integration data and deploying the migrated data in the target environment.

Migrating application integration data is straightforward when migrating between WebLogic Server domains the Enterprise Information System (EIS) when instances do not change. However, if the EIS instances do change, you must follow special procedures to ensure a working solution in the target environment.

This section provides information on migrating application integration data between WebLogic Server domains in the following scenarios:

Migrating Data Within the Same EIS Instance

This section describes how to migrate application integration data between WebLogic Server domains, when the EIS instances involved do not change. An example of this type of migration is moving application view definitions between repositories for different domains of WebLogic Integration. In this case, only the WebLogic Integration domain changes, but the target EIS instances referred to in the application views remain the same.

In this case, the BPM package import/export utility makes migrating data simple. It involves exporting a package from BPM in the source domain, and importing that package into BPM in the target domain.

For more information on the BPM package import/export utility, see "Importing and Exporting Workflow Packages in Using the WebLogic Integration Studio.

Export

When exporting a workflow that utilizes application integration, the BPM export tool automatically identifies the application views and other resources the workflow depends on. Listing A-1and Listing A-2 show general values identifying an application view and the resources it depends on in the export tool. In general, the application view will be located (in the BPM export tool) in the location shown in Listing A-1.

Listing A-1 Application View Location in the BPM Export Tool

All Workflow Objects
    |--  XML Repository
        |-- Folder: WLAI.Namespace.Root
            |-- Folder: WLAI.Namespace.Root.<first folder>
                |-- Folder: WLAI.Namespace.Root.<first folder>.<nth folder>
                    |-- Entity: WLAI.ApplicationView.Root.<first folder>.
                                              <nth folder>.<appview name>

In general, all entities related to the application view can be found under the <nth folder>, and will be named according to the convention shown in Listing A-2. All application views may not follow this convention.

Listing A-2 Application View Resource Locations in BPM Export Tool

Entity: WLAI.<entity type>.Root.<first folder>.<nth folder>.<appview name>_<event/service name>_<adapter_specific>

To fully export an application view, you must select all entities that are related to the application view, if not already selected. This includes entities of type Schema and type ConnectionFactory.

Export Example

For example, an application view named CustomerManagement in the folder EastCoast.Sales would be displayed in the BPM export tool at the location shown in Listing A-3.

Listing A-3 Application View in the BPM Export Tool

All Workflow Objects
    |--  XML Repository
        |-- Folder: WLAI.Namespace.Root
            |-- Folder: WLAI.Namespace.Root.EastCoast
                |-- Folder: WLAI.Namespace.Root.EastCoast.Sales
                    |-- Entity:WLAI.ApplicationView.Root.EastCoast.
                                            Sales.CustomerManagement

In order to fully export the CustomerManagement application view, the export tool automatically selects all entities that conform to the following pattern

Entity: WLAI.<entity type>.Root.EastCoast.Sales.CustomerManagement

For example, the CustomerManagement application view may contain several events and services. The export utility shows one Schema type entity for each event and two Schema type entities for each service. For example, where the CustomerManagement application view uses the DBMS adapter and has one event namedCustomerCreated and one service named CreateCustomer, the entities shown in Listing A-4 are shown in the BPM export utility.

Listing A-4 Entities Used by the Application View

Entity: WLAI.Schema.Root.EastCoast.Sales.CustomerManagement_CustomerCreated_
CUSTOMER_TABLE_insert

Entity: WLAI.Schema.Root.EastCoast.Sales.CustomerManagement_CreateCustomer_input

Entity: WLAI.Schema.Root.EastCoast.Sales.CustomerManagement_
CreateCustomer_output

The CustomerManagement application view also includes a single connection factory. The entity name for this connection factory is as follows:

Entity: WLAI.ConnectionFactory.Root.EastCoast.Sales.CustomerManagement.
ConnectionFactory

Each of these entities must be selected to properly export the CustomerManagement application view.

Import

Use the BPM package import utility to import a package containing application integration data. This utility automatically imports all entities you exported into the package. Before you can use the application views you just imported, you must ensure that they are deployed.

Deploy your imported application views using the WebLogic Integration Application View Console (generally located at http://<server>:<port>/wlai). Navigate through the imported folders to find the imported application view. Select the application view, and click the Deploy button on the Application View Summary page. This makes the application view ready for use in the target environment.

Migrating Data Within Different EIS Instances

This and the previous scenarion use the same procedures for export and import; however, some additional steps are required in the import procedure.

Special care must be taken when migrating data between WebLogic Server domains and between different instances of an EIS, because application views defined against one EIS instance contain identifiers and other data specific to that EIS instance. This is also true of the connection factory used by the application view.

You must manually change EIS-instance-specific data in your application view or connection factory. You can make these changes from the Application View Console by navigating to the desired application view and editing the application view. You must identify and update all EIS-specific data in the application view and its events, services and associated connection factory. Search for any EIS-instance-specific references, and replace them with references to the new EIS instance in the target environment.

In particular, you must edit the application view and connection factory definitions. Application view definitions may need changes in the following areas:

The EventRouterURL parameter of the ApplicationView deploy screen. This must refer to the event router in the target environment.
Parameters in the service definitions. These are adapter-specific data that might refer to EIS-instance-specific data. Use the Edit feature to change any EIS instance-specific parameters for the service.
Parameters in the event definitions. These are adapter-specific data that may refer to EIS-instance-specific data. Use the Edit feature on the Application View Summary page to change any EIS instance-pecific parameters for the service.

Import Example

In the CustomerManagement example, we have a database called CUST in the source environment, and we have a database called CustDB in the target environment. Listing A-5 shows the XML text that represents the application view and connection factory. More specifically, the example shows the application view descriptor for the CustomerManagement application view. When you use the Application View Console, you will need to use the appropriate fields in the design-time UI forms to see view and edit this information.

Listing A-5 Example XML Text for the Application View and Connection Factory

<?xml version="1.0"?>
<!DOCTYPE applicationView>
<applicationView asyncEnabled="true"
connectionFactory="com.bea.wlai.connectionFactories.EastCoast.Sales.
CustomerManagement_connectionFactoryInstance"
connectionFactoryName="EastCoast.Sales.CustomerManagement_connectionFactory"
eventRouterURL="http://localhost:7001/DbmsEventRouter/EventRouter"
            name="CustomerManagement"
            ownsConnectionFactory="true">
    <description>Manages customers in the east coast sales database</description>

    

    <service interactionSpecClass="com.bea.adapter.dbms.cci.InteractionSpecImpl"
            name="CreateCustomer"
            ownsRequestSchema="true"
            ownsResponseSchema="true"
requestDocumentType="EastCoast.Sales.CustomerManagement_CreateCustomer_input/Input"
responseDocumentType="EastCoast.Sales.CustomerManagement_CreateCustomer_output/RowsAffected">
      <description>create a new customer in database</description>
      <interactionSpecProperty name="functionName">executeUpdate</interactionSpecProperty>
      <interactionSpecProperty name="sql">insert into CUST.dbo.CUSTOMER_TABLE
(FirstName, LastName, DOB) values ([FirstName varchar], [LastName varchar], [DOB
timestamp])</interactionSpecProperty>
      </service>

      <event name="CustomerCreated"
            ownsSchema="true"
            rootElementName="CUSTOMER_TABLE.insert"

schemaName="EastCoast.Sales.CustomerManagement_CustomerCreated_CUSTOMER_TABLE_insert">
      <description>New customer created in database</description>
      <eventProperty name="tableName">CUSTOMER_TABLE</eventProperty>
      <eventProperty name="triggerType">insert</eventProperty>
      <eventProperty name="catalogName">CUST</eventProperty>
      <eventProperty name="schemaName">dbo</eventProperty>
    </event>

</applicationView>

Note that this application view contains:

Explicit reference to the event router URL (likely different in the target domain if you changed EIS instances).
interactionSpecProperty elements with explicit SQL statements (the <service> element) that refer to the CUST database, the dbo schema, and the CUSTOMER_TABLE table.
eventProperty elements that refer to catalogName as CUST and schemaName as dbo. In this example, all references (highlighted in the above text) to CUST must be changed to CustDB. If the schema were different, the schema references must also be changed.

Each adapter places different properties into the service and event descriptors of application view descriptors it creates. Refer to your adapter documentation for information on what properties must be changed to operate successfully against a new EIS instance.

The connection factory descriptor will also need to be changed to refer to the new EIS instance. Listing A-6 shows sample connection factory.

Listing A-6 Example Connection Factory

<?xml version="1.0"?>
<!DOCTYPE connection-factory-dd>
<connection-factory-dd name="CustomerManagement_connectionFactory">
    <jndi-
name>com.bea.wlai.connectionFactories.EastCoast.Sales.CustomerManagement_connectionFactoryInstance</jndi-name>
    <pool-parms allowPoolToShrink="true"
            maxPoolSize="10"
            minPoolSize="0"
            targetFractionOfMaxPoolSize="0.1"/>
    <mcf-parm name="MessageBundleBase">
        <mcf-parm-value>BEA_WLS_DBMS_ADK</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="DataSourceName">
        <mcf-parm-value>eventSource</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="AdditionalLogContext">
        <mcf-parm-value>CustomerManagement</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="UserName">
        <mcf-parm-value>system</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="Password">
        <mcf-parm-value>security</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="RootLogContext">
        <mcf-parm-value>BEA_WLS_DBMS_ADK</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="PingTable">
        <mcf-parm-value>CUST.dbo.CUSTOMER_TABLE</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="LogLevel">
        <mcf-parm-value>WARN</mcf-parm-value>
    </mcf-parm>
    <mcf-parm name="LogConfigFile">
        <mcf-parm-value>BEA_WLS_DBMS_ADK.xml</mcf-parm-value>
    </mcf-parm>
    <adapter-logical-name>BEA_WLS_DBMS_ADK</adapter-logical-name>
</connection-factory-dd>

Note that this connection factory descriptor refers to directly to the CUST database and to a JDBC data source named eventSource. To ensure this connection factory will operate properly in the target environment, you must change the reference to CUST to be CustDB, and change the eventSource JDBC data source reference to refer to a valid JDBC data source (pointing at the new DBMS hosting CustDB) in the target domain.

At this point, you have modified references and ensured that all the resources needed by the application view and connection factory exist in the target domain. You may now deploy all the application views you imported. Deploy application views using the Application View Console (generally located at http://<host>:<port>/wlai).

Recommended Practices

The following are suggestions to help reduce the effort needed to migrate application integration data between environments.

Wherever possible, set up identical EIS instances in both the source and target domain. For example, use a source and target database (for application views that use the DBMS adapter) that have the same type (for example, MS SQL Server to MS SQL Server), the same name, user accounts, and database objects. This eliminates the need to manually edit application view and connection factory descriptors.
Remember to change the event router URL to reflect the event router's location in the target environment. This can be changed by editing the application view from the application integration Application View Console.
Remember to deploy your application views after they are imported using the Application View Console.