Migrating Application Integration Data

This section presents the following topics:

• Overview of Migrating Data

• Migrating Data Within a Single EIS Instance

• Migrating Data Within Multiple EIS Instances

• Recommended Practices

 

---

Overview of Migrating Data

Configuration data for application integration functions is stored in the same repository as configuration data for business process management (BPM) functions. Therefore, you can use the same tools to migrate data for both types of functions. However, several special considerations apply to the migration of application integration data and deployment of that data in the target environment.

Note: The application integration engine now supports modular deployment. It is bundled in an enterprise application archive (EAR) file and is available to any valid WebLogic domain. Because the BPM capabilities may not always be installed, a command-line interface to the import / export tool is provided for Application Views. For more information, see Importing and Exporting Application Views.

Migrating application integration data is straightforward when you are migrating between WebLogic Server domains within a single Enterprise Information System (EIS) instance. When you migrate application data between WebLogic Server domains in different EIS instances, however, you must perform special procedures to ensure a working solution in the target environment.

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

• Migrating Data Within a Single EIS Instance

• Migrating Data Within Multiple EIS Instances

 

---

Migrating Data Within a Single EIS Instance

This section describes how to migrate application integration data among multiple WebLogic Server domains within a single EIS instance. For example, you might move Application View definitions between repositories for different domains of WebLogic Integration. In this case, only the WebLogic Integration domain changes; the target EIS instances referred to in the Application Views remain the same.

In this case, the workflow package import/export utility (accessible from the WebLogic Integration Studio) simplifies the job of migrating data. It involves exporting a package from the Studio in the source domain, and importing that package into the Studio in the target domain.

For more information about this import/export utility, see Importing and Exporting Workflow Packages in Using the WebLogic Integration Studio.

How an Application View Is Exported

When you export a workflow that includes application integration functionality, the export tool automatically identifies the Application Views and other resources on which the workflow depends. Listing  A-1 and Listing  A-2 show values identifying an Application View and the resources on which it depends in the export tool. In general, the Application View value is displayed (in the 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.firstfolder
                |-- Folder: WLAI.Namespace.Root.firstfolder.nthfolder
                    |-- Entity: WLAI.ApplicationView.Root.firstfolder.
                                              nthfolder.appviewname

In general, entities related to the Application View can be found under the nth_folder, and are named according to the convention shown in Listing  A-2. Not all Application Views follow this convention, however.

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

Entity: WLAI.entity_type.Root.firstfolder.nthfolder.appviewname_event/
servicename_adapterspecific

To fully export an Application View, you must select all entities that are related to it, including entities of Schema and ConnectionFactory types.

Example Application View Export

The EastCoast.Sales folder contains an Application View named CustomerManagement which is 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

To fully export the CustomerManagement Application View, the export tool automatically selects all entities that conform to the following pattern:

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

The CustomerManagement Application View contains several events and services: the export utility shows one Schema type entity for each event and two Schema type entities for each service. The CustomerManagement Application View also uses the DBMS adapter, and includes one event named CustomerCreated and one service named CreateCustomer. Therefore, the entities shown in Listing  A-4 are listed by the 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 

For the CustomerManagement Application View to be exported properly, all the entities shown in Listing  A-4 must be selected.

Importing an Application View

To import an Application View, perform the following steps:

1. Using the workflow package import utility (accessible from the WebLogic Integration Studio), import a package containing application integration data. The utility automatically imports all the entities you exported into the package earlier.

2. Deploy your imported Application Views using the WebLogic Integration Application View Console (generally located at http://server:port/wlai).

3. Navigate through the imported folders to find the imported Application View.

4. Select the appropriate Application View. Then select the Deploy option on the Application View Summary page.

The Application View is now ready for use in the target environment.

 

---

Migrating Data Within Multiple EIS Instances

Be careful when migrating data among WebLogic Server domains and between multiple instances of an EIS, because Application Views defined for a particular EIS instance contain identifiers and other data specific to that instance. This advice also applies to the connection factory used by the Application View.

To prevent possible errors, you must manually change EIS instance-specific data in your Application View or connection factory by performing the following steps:

1. Open the Application View Console.

2. Navigate to the appropriate Application View and edit it as necessary:

   1. Identify and update all EIS-specific data in the Application View and the events, services, and connection factory associated with that Application View.

   2. Search for any EIS-instance-specific references, and replace them with references to the new EIS instance in the target environment.

Be sure to edit the Application View and connection factory definitions. The following parameters of the Application View definitions may need to be changed:

• The EventRouterURL parameter of the ApplicationView deploy screen 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. Change any EIS instance-specific parameters for the service as necessary.

• 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-specific parameters for the service.

Example Application View Import

The CustomerManagement example includes a database called CUST, in the source environment, and a database called CustDB in the target environment. Listing  A-5 shows the XML text that represents the Application View and connection factory. Specifically, this listing shows the Application View descriptor for the CustomerManagement Application View. When you use the Application View Console, you must use the appropriate fields in the design-time UI forms to 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>

This Application View contains:

• Explicit reference to the event router URL. (The URL is probably different in the target domain from that in the original domain if you change EIS instances.)

• interactionSpecProperty elements with explicit SQL statements (expressed with 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 to CUST (highlighted in the preceding text) must be changed to CustDB. If a different schema is used, the schema references must also be changed.

Each adapter puts different properties in the service and event descriptors of the Application View descriptors it creates. For information about which properties must be changed to operate successfully with a new EIS instance, see your adapter documentation.

You must also change the connection factory descriptor so that it refers to the new EIS instance. Listing  A-6 shows a sample connection factory.

Listing A-6 Sample 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>

As shown in the preceding code, this connection factory descriptor refers directly to the CUST database and to a JDBC data source named eventSource. To make sure that this connection factory operates properly in the target environment, you must make the following changes:

• Change the reference to CUST toa reference to CustDB

• Change the eventSource JDBC data source reference so it refers to a valid JDBC data source (pointing at the new DBMS that is hosting CustDB) in the target domain.

At this point, you have modified all necessary 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, using the Application View Console (generally located at http://host:port/wlai).

 

---

Recommended Practices

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

• Whenever possible, set up identical EIS instances in both the source and target domains. For example, in the Application View in which the DBMS adapter is used, you might use two instances of MS SQL Server (with the same name, the same user accounts, and the same database object) for both your source and target databases. This type of setup eliminates the need for manual editing of Application View and connection factory descriptors.

• Change the event router URL to reflect the event router's location in the target environment. To do so, edit the Application View in the Application View Console.

• After your Application Views are imported, deploy them using the Application View Console.