WebSphere Data Interchange, Best Practice, Deploying from Test to Production

Content

Deploying WDI Objects from Test to Production

When changing a production environment, it is important to monitor the change made and provide a process that will insure minimal negative impact. WDI, as with any software, requires change. These changes can be grouped into two categories: 1) business object changes, i.e. changes to maps, addition to Trading Partner community, implementation of new process flows, and 2) product maintenance, e.g. a set of corrections to the product in a fix pack, or a set of feature enhancements as with a new version or release of the WDI product.

A commonly accepted practice for controlling change and verifying a minimal impact is to provide multiple environments in which development and quality assurance can take place. In today's 24 x 7 world, this usually means redundant environments which have no impact on production when bad things occur. This document discusses the 'three system' model, but it should be adapted to the size and scope of the business enterprise. The principles will be the same.

In a 'three system" model, there are three environments to be maintained: 1) the production environment in which mission critical applications and day to day work is executed, 2) a pre-production/test or quality assurance region in which changed applications and software are tested under near-production conditions, and 3) a development region in which new or changed business objects are tested and changes to software are reviewed.

Choosing a technique that fits

• Regression Test

A regression test is as complex or as simple as you require. It implies that there are a series of test cases that you feel must operate the same regardless of changes made.

Best Practice suggestion

Create a set of test cases and expected results.
Run the test cases prior to a change (map change / or Server Fix Pack)
Save the results; they will become the expected results
Run the identical test cases after a change
Verify results match expected results or can be explained by the change; these then become the expected results for the next iteration of regression

• Map Change Control

Identify when and by whom changes are made to map objects and other mission critical WDI objects

Best Practice suggestion

Developers will record date and change description in Map Comment area.
QA verifies compliance and moves object into Production

Alternate approach

Use WDI Export / Import to move Map export object to source control system, and then have QA import Map object into production; this provides a revision history above the manual approach.

Diagram







• Security


WDI uses DB2 security to control access to DB2 Tables. By controlling access to various tables within the product, an installation can control access to WDI functions by user functional group within an individual system, e.g. Production. The WDI Client Role Based-access controls also provide functional separation of tasks.

Best Practice Suggestion

1) Trading Partners, Profiles, Code Lists, Validation and Translation Tables, Event Log, Management Reporting, and Transaction Store are "Runtime" objects and must be available for translation to occur. Use DB2 GRANT to insure that appropriate staff have UPDATE/INSERT access
2) Restrict Maps, Standards, Data Formats, XML objects using DB2 GRANT to those with need to know. WDI transforms using WDI Control Strings which are derived from the Maps, Standards, Data Formats, etc.
3) An alternate practice is to move only WDI Control Strings into Production system

WDI Client View option is also available. This allows a DB2 GRANT with SELECT authority to be recognized.

In WDI v3.3, Role-based access defined with the WDI Client can be coupled with RACF or DB2 security to partition users from WDI objects.

• Installation Testing Considerations


• New Installation

Readme.text describes the installation steps necessary for successful implementation of WDI. It describes the multiple scenarios in WDI in which the installation can take place
1. new product at Server Fix Pack level
2. provided database vs purchased DB2
3. MQSeries install level
4. describes new features, additional version support, and defects resolved

The WDI Installation Guide also is useful in understanding the order and impact of changes, and of different configurations for the WDI Server and WDI Client

Best Practices suggestion

The best practice for Installing WDI in a new environment is to apply the Base Install CDs and then apply the latest Server Fix Pack to that base BEFORE creating the product tables. In this way, the latest changes are implemented with the allocation of DB tables and the loading of initial data.

The LOADMSGS exec reloads the WDI Message table.

The BINDGRNT exec (DB2 BIND and DB2 GRANTs) must be run.

• Server Fix Pack Installation

Server Fix Pack Installation implies that a Service Fixpack (aka CSD) is being applied to an existing WDI implementation. A primary goal is to not disturb the existing Database and its contents.

Follow the readme carefully. Some levels of Client Fix Packs must be synchronized with level of Server Fix Packs.

Server Fix Packs and Client Fix Packs are expected to be installed intact and not in pieces.

Best practices Suggestion

1) in Production, apply as little maintenance as possible to a stable environment
2) in Test, maintain the same environment level as production, except when migrating new maps, or configurations to production, then regression test in the Test system with the same maintenance level of development, then implement Fix Packs and maps together
3) in Development, keep current with fix pack maintenance if "actively" developing.

• Client Fix Pack Installation

A Client Fix Pack must be applied to the hardware of each WDI Client user. Normally, the Client CONFIG DB is not altered during Client Fix Pack installation. The CONFIG DB contains user queries, user preferences, and user systems. A database is provided with the client install that is different than the DB2 databases. This local machine database is a user "sandbox". Objects may be moved to the Development database.

Follow the readme carefully. Some Client Fix Packs must be synchronized with Server Fix Packs. A "Release Migration" may be appropriate to retain local machine objects - include the provided database.

Best practices Suggestion

1) in Production, apply as little maintenance as possible to a stable environment
2) in Test, maintain the same environment as production, except when migrating new maps, configurations to production, then regression test in Test system with maintenance level of development, and implement together
3) in Development, keep current with maintenance if "actively" developing.

Recommended configuration

The following configuration combines elements of a source code control system with a rigidly managed deployment process for changes in a multiple translation server environment. This configuration uses both PC and server databases. It makes extensive use of client-server access, along with the Export to System function within WebSphere Data Interchange Client to move objects, such as maps and DTDs, from system to system.

Multi-user, multi-server with both stand alone and client-server access

Each developer has a local database that resides on their PC. In addition, three server DB2 repositories are shared by developers, testers, and administrators.

• Complex setup, higher cost.
• Sharing between developers is easy because there is a single DB2 repository for all build time objects.
• Minimum response time is ensured for developers by keeping items currently in progress in a local database.
• Minimizes potential contamination of test environment by developers by separating the test database from the development database, and allowing only testers to have access to the test database.
• Minimizes potential contamination of the production environment by testers or developers by separating the production database from the test and development databases, and not allowing testers or developers access to the production database.
• Minimizes potential contamination of complex build time objects (XML, EDI standard, and Data Format document definitions, along with maps) by not deploying them to the test and production environment. Only runtime objects (such as profiles, usages, rules, and control strings) are deployed, so testers and administrators cannot change build time objects.
• Check-out, check-in, and manual deployment (or promotion) of objects can be done directly by an authorized user with the WebSphere Data Interchange Client Export to System function.
• Deployment can be automated with the use of the PERFORM EXPORT and PERFORM IMPORT server commands. This is a good alternative for a medium to large scale B2B (Business to Business) shop.

The following is an illustration of the recommended configuration.



Setup example

Install WebSphere Data Interchange Client (Typical) on the PC of each user (developer, tester, or administrator).

• For developers, install the local database and set up their computers for ODBC access to the development database.
• For testers, do not install a local database. Set up their computers for ODBC access to the test database, and if manual deployment will be allowed via Export to System, then also set up access to the development database.
• For administrators, do not install a local database. Set up their computers for ODBC access to the production database and if manual deployment will be allowed via Export to System, then also set up access to the test database.

Establish check-in and check-out procedures for the developers. WebSphere Data Interchange does not provide a check-in, check-out mechanism, so this must be done manually.

Establish procedures for deploying (or promoting) objects. If automated deployment is to be used, write the deployment JCL jobs, or scripts.

Running WebSphere Data Interchange Client

WebSphere Data Interchange Client is designed to prevent more than one user from working on the same item at the same time. As a result, you need to log on to WebSphere Data Interchange Client databases every time you start the software, as follows.

Select WebSphere Data Interchange from the WebSphere Data Interchange item on the Start menu.
Note: If you are using a multi-user or client-server setup, your User ID and Password are determined by your system administrator.

You are now ready to connect to the system that displays in the System drop-down list. To change which system will be accessed, select an alternate system name from the list.
Attention: Use the ODBC Administrator in the Windows Control panel to set up your passwords if you do not want to type your passwords every time you access a system.

You can work on items in different systems at the same time. For example, you can edit a map from the Development system while also editing one from the Test system.