![]() |
![]() |
|
|
Migrating Application Integration Data
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:
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:
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.
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|