SeeBeyond WebSphere MQ to BizTalk Conversion
BizTalk Server is a Proven Alternative to SeeBeyond
|
On This Page
 | Introduction |
| Functionality |
| Migration to BizTalk Server |
| WebSphere MQ Tips and Tricks |
| Conclusion |
| About the Author |
Introduction
Microsoft has raised the bar for enterprise integration software in the industry with the introduction of BizTalk Server. Contoso, a fictitious organization that is based on a real organization, currently uses SeeBeyond for enterprise application integration and trading partner integration.
Contoso is a consumer packaged goods company that specializes in producing computer widgets. Contoso believes in integrating disparate systems within the organization and with trading partners outside the organization to maximize the value of their e-commerce data.
Contoso currently uses WebSphere MQ, a robust messaging platform that is one of the most common methods of communicating with host applications (MVS, AS400, and so forth) to connect with SeeBeyond.
The following diagram shows a high-level overview of the current architecture for Contoso and a trading partner.
Contoso wants to convert its SeeBeyond system to Microsoft BizTalk. Only one SeeBeyond Administrator fully understands the entire SeeBeyond system. This administrator is the only person who has participated in all phases of implementing the SeeBeyond Solution including:
| • | Installation |
| • | Configuration |
| • | Deployment |
| • | Support |
However, the SeeBeyond Administrator resigned at the beginning of the integration project. With the Administrator gone, there is no one at Contoso who has an end-to-end understanding of either their trading partner integration functionality or their internal application integration requirements. In addition, Contoso executives want to reduce resource consumption, reduce the complexity of upgrades, and include additional extensibility for future projects. They want to achieve these objectives while reducing both the amount of custom coding and total cost of ownership!
This is truly one of the very real nightmares that integrators face. Microsoft provides a solution to help in this scenario. Microsoft BizTalk provides the fundamental tools to help replace the integration, workflow, and general functionality offered by SeeBeyond.
We will begin by examining some of the functionality offered by SeeBeyond, specifically, the Integration Composite Application Networks Suite (ICAN) and the eWay Intelligent Adapters. With the popularity that I have seen with WebSphere MQ, this whitepaper will focus on replacing SeeBeyond with BizTalk while maintaining the WebSphere MQ infrastructure.
In essence, BizTalk Server will treat SeeBeyond as a black box.
The following table summarizes the Contoso requirements and describes the Microsoft BizTalk capabilities of meeting and surpassing those requirements.
| Requirements | Microsoft Solution |
Reduce resource consumption and complexity for upgrades | The number of Microsoft developers and BizTalk developers are growing every day. The BizTalk environment/architecture, coupled with Visual Studio Integrated Development Environment, allows for easier and simpler upgrades. |
Reduce amount of custom coding | BizTalk Server is a drag-and-drop interface. Any coding done uses .NET and .NET has a very large development community. |
Reduce TCO and maintenance cost | BizTalk Server contains the full solution in one package at a much lower cost. |
Allow for extensibility | BizTalk Solutions are easily extensible because of their tight integration with the Windows Server System. |
The solution is clear—Microsoft BizTalk Server is more than capable of meeting the requirements that Contoso executives have set.
SeeBeyond (ICAN)
SeeBeyond began in 1989 as a health care integration company. SeeBeyond has increased its scope and interests to other industries with a strong focus on application integration. In October of 2003, SeeBeyond launched the Integrated Composite Application Networks Suite, version 5.0. (ICAN 5). ICAN 5 is a suite of 12 solutions that together comprise a standards-based, business-process, management-focused solution. Of the twelve solutions, six are revised legacy solutions based on version 4.5.3 of its product, and six are new. This new version of ICAN centers on Web Services and is now compliant with J2EE and Business Process Execution Language for Web Services (BPEL4WS).
The heart of the ICAN 5 suite is eGate Integrator 5 (eGate 5) with its array of over 80+ eWay Adapters.
Unfortunately, for customers currently using version 4.5.3, there is no clear migration path offered for them to upgrade to ICAN 5.0.
BizTalk Server
BizTalk Server is a platform that is redefining the standards of business process development and deployment. BizTalk Server does this using a scalable, extensible, and robust publish and subscribe framework that integrates messaging and orchestrations.
BizTalk Server has an extensive third-party adapter community as well as several OEM adapters that are developed based on the Adapter Framework.
BizTalk Server is the fastest-growing integration software platform with over 4800 customers in just over 4 years.
WebSphere MQ (Formerly IBM MQSeries)
IBM MQ Series provides a reliable messaging backbone for deploying an organization's enterprise service bus (ESB) as the connectivity layer that lays the groundwork for a service-orientated architecture (SOA). Not too long ago, IBM decided to strengthen its WebSphere family by incorporating MQSeries in May of 2001, which gave birth to WebSphere MQ.
WebSphere MQ's message queuing technology provides "guaranteed message delivery." This means that if a message was to get transmitted and the power cord and the network cord were to be pulled, once everything was plugged back in (and the environment returned to normal) the recipient of the message will receive the message.
In addition, WebSphere MQ can live in a variety of environments, including:
| • | Native z/OS |
| • | HP-UX |
| • | Linux |
| • | Solaris |
| • | I5/OS, OS/400 |
| • | AIX |
| • | Windows |
It is not uncommon to see implementations of WebSphere MQ with SeeBeyond on any of the above operating systems. We will provide a much deeper focus on interfacing with WebSphere MQ when replacing SeeBeyond later.
Functionality
Engagements usually show the ICAN suite involved in fulfilling the integration role between the trading partners and the internal systems of the organization.
The following diagram shows some of the protocols that ICAN is able to interact with external trading partners. These include but are not limited to:
| • | HTTP/s |
| • | WebSphere MQ |
| • | Secure Web services |
| • | FTP |
ICAN also communicates with internal systems such as:
| • | Enterprise Resource Planning (ERP) |
| • | Customer Relationship Management (CRM) |
| • | Fulfillment systems |
| • | Data warehouse systems |
Contoso and similar organizations will always have to communicate with their trading partners using several protocols. The information received from these trading partners is required by different units in the Contoso organization to truly maximize value and efficiencies. For example, receipt of a purchase order from a trading partner will affect many systems in Contoso's infrastructure. This can include:
| • | CRM updates to document any changes in the customer preference |
| • | ERP verification to validate that inventory exists to fill order |
| • | Fulfillment system entries to prepare an Advance Shipping Notice (ASN) to send when the order is ready to be shipped |
Each one of these workflows may need to be completed using any of the aforementioned protocols including WebSphere MQ.
For the purpose of focusing on WebSphere MQ, we will assume that one of Contoso's trading partners, Trading Partner A (TPA), uses WebSphere MQ to pass XML messages to Contoso. TPA requires guaranteed message delivery. The information is transmitted directly to TPA's WebSphere MQ system on OS/390. Contoso currently uses the eWay Intelligent Adapters to connect to WebSphere MQ at TPA.
Migration to BizTalk Server
To continue with the Contoso example, the executives at Contoso have many disparate systems to which they need to connect internally as well as externally with trading partners. An increasing number of different types of connectivity and trading partner integration will be required in the near future. Contoso now faces many challenges including:
| • | Upgrading to ICAN version 5 when no clear migration path exists for migrating their solution from version 4.5.3 to ICAN 5. |
| • | Minimizing custom coding in proprietary languages |
| • | Reducing integration costs |
| • | Leveraging a product with a present and future focus on Vertical and Enterprise Application Integration |
| • | Dealing with reduced resources and expertise as the Contoso SeeBeyond administrator recently resigned |
In an effort to resolve these issues, Contoso executives approach Microsoft and the Microsoft Partner Community.
Project Requirements of Migrating to BizTalk Server
Microsoft and its partner have visited Contoso and have completed the envisioning and planning phase while adhering to the MSF (Microsoft Solution Foundation). This phase revealed the following information:
Trading Partners
| External Trading Partner | Connection Channel | Inbound Transactions | Outbound Transactions |
Trading Partner A | HTTPS | Item lookups, order entries in XML with full documentation | Item return and order confirmation in XML with full documentation |
Trading Partner B | WebSphere MQ | Item lookups, order entries in flat file with full documentation | Item return and order confirmation in Flat File with full documentation |
Trading Partner C | Secure Web services | Item lookups, order entries in XML with full documentation | Item return and order confirmation in XML with full documentation |
Trading Partner D | FTP | Order entry in flat file format with full documentation | Order confirmation in flat file with full documentation |
Internal Connectivity
| Internal | Application | Inbound Transactions | Outbound Transactions | Documentation |
AS/400 | CRM | Flat Files | Flat Files | Full |
OS/390 | ERP | XML | XML | Full |
DB2 on AIX | Fulfillment System | Application Direct Connect | Application Direct Connect | Full |
Based on the above information, we understand and have complete documentation about the information going into and coming out of SeeBeyond.
Development Approach with BizTalk Server
Upon completion of the envisioning and planning stage, we have full documentation of the messages that are consumed by SeeBeyond and the resulting message output. Therefore, one of the best approaches is to treat SeeBeyond as a "Black Box".
Figure 3 - Black Box Approach
Using the Black Box approach we do not need to know what is in the SeeBeyond system. The Black Box must simply consume the messages brought into it and return the messages that are expected.
ICAN provides three basic categories of functionality which BizTalk Server is able to accommodate very easily.
| SeeBeyond functionality | Replace with BizTalk Server functionality |
Workflow and business logic | BizTalk orchestration designer, business rules engine, .NET components |
Message creation/transformation | BizTalk Mapper, BizTalk Editor, and Pipeline Designers |
Connectivity to internal/external sources | BizTalk Server contains the full solution in one package at a much lower cost |
Let's examine each of these functional requirements in more detail:
| • | Workflow and business logic – The BizTalk Orchestrations Designers can provide the workflow design in a drag and drop format. Business rules, depending on how dynamic they are, can be handled using either the Business Rules Engine or Expressions. Additional customizations are available with .NET components that can be called from BizTalk Orchestrations via a web service. |
| • | Message Creation/Transformation – Messages (schemas) can be created and mapped using the BizTalk Editor and Mapper respectively. The Pipelines contain the components necessary to disassemble flat files coming in and reassemble them going out. |
| • | Connectivity to internal/external sources – BizTalk server provides the ability to connect to various external sources out of the box. In addition, there is a large community of partners that concentrate solely on writing adapters to allow BizTalk to connect to almost anything. |
After careful evaluation, Contoso determined that BizTalk Server is able to replicate the existing SeeBeyond functionalities, as well as accommodate the additional business and functional requirements Contoso demands. Contoso decided to migrate to BizTalk Server.
The remainder of the whitepaper will focus on the connectivity to WebSphere MQ.
Connectivity to WebSphere MQ
IBM WebSphere MQ is a very popular product and is prevalent in many SeeBeyond scenarios. Contoso also used to use ICAN to integrate with MQ with one of its trading partners.
WebSphere MQ Connectivity Scenarios
The architecture for BizTalk and WebSphere MQ connectivity depends heavily on the requirements of the business, the infrastructure in place at Contoso, and the privileges and access allowed by Contoso's trading partner running WebSphere MQ.
WebSphere MQ Architecture Criteria
The following points describe the factors used to determine the BizTalk/WebSphere MQ architecture at Contoso:
| • | MQ Server at Contoso runs on Windows - Contoso must have an MQ Server running on a Windows Operating system, such as Windows 2000, Windows 2003 and so on. | ||||||||
| • | MQ Server at Contoso Trading Partner runs on Windows – Contoso's trading partner has a MQ Server that is running on a Windows Operating system. | ||||||||
| • | Contoso Trading Partner allows changes to MQ Infrastructure – Contoso's trading partner allows for modifications to both their MQ Infrastructure as well as to the internal firewall to allow for MQ, COM and/or COM+ unrestricted traffic between Contoso and the trading partner. Modifications to the MQ Infrastructure include:
| ||||||||
| • | Guaranteed Message Delivery Required – The ability for persistent MQ messages to be delivered only once. | ||||||||
| • | Push and Pull Notification – Push notification means that Contoso is notified when a message arrives on its local queue. Pull notification means that Contoso must constantly query its local queue to identify new messages. The ability to receive both types of notifications reduces the latency time of processing messages as they arrive. |
BizTalk Adapter for WebSphere MQ v2.0
The BizTalk Adapter for WebSphere MQ v2.0 is a free download from Microsoft and is used only when there is adequate network connectivity to a WebSphere MQ server that is running on a Windows Operating System. This is necessary as a component is required to be installed on that MQ Server.
This solution offers the most benefits as it leverages an MQ to MQ scenario and offers the flexibility of Push and Pull notification, Guaranteed Message Delivery as well as inherent WebSphere MQ high availability.
BizTalk will access WebSphere MQ locally and have the ability to be notified of messages or place messages into queues.
The following diagram is a high level architectural overview of the BizTalk Adapter for WebSphere MQ v2.0:
Figure 4 - High Level Overview of BizTalk Adapter for WebSphere MQ v2.0
Installing the BizTalk Adapter for WebSphere MQ v2.0
The following steps illustrate how to install the BizTalk Adapter for WebSphere MQ v2.0.
After downloading the installation package from the Microsoft Web site, extract the package to a directory on the BizTalk Server. Double-click the Setup.exe file in the installation directory. The following screen appears:
Figure 5 - BizTalk Adapter for MQ Series Install Screen
Click the Install icon, and the welcome screen will appear.
Figure 6 - BizTalk Adapter Setup Screen
Read the warnings, and click Next to continue with the installation.
Read the License Agreement, select I accept the License Agreement, and then click Next.
Figure 7 - License Agreement
Enter a full name and name of the organization, and click Next to continue with the installation.
Figure 8 - User Information
Either accept the default directory or change it using the Browse button. There is only one feature to install, so you do not have to select which features to install. When finished, click Next.
Figure 9 - Select Features
Click Install to start the installation process.
Figure 10 - Adapter Setup
The installation will continue.
Figure 11 - Update System
When the completion screen displays, click Finish to complete the installation.
Figure 12 - Completing Installation
Adding the BizTalk Adapter for WebSphere MQ v2.0 to BizTalk
To add the BizTalk Adapter, you must first start the BizTalk Server Administration Tool.
Figure 13 - BizTalk Administration Console
In the BizTalk Administration Console, click the plus (+) sign next to Microsoft BizTalk Server 2004 (Local) to expand the contents.
Figure 14 - Adapter View
Right-click the Adapters folder and click Select New, and then click Adapter. The Add Adapter screen will appear.
Figure 15 - Add Adapter
Type the information in the text boxes as follows, and then click OK. Note that MQSeries now appears in the Adapter list box.
Figure 16 - MQSeries Adapter
Note that the MQSeries Adapter now appears in the list of Adapters in the BizTalk Administration tool.
Figure 17 - Console with New Adapter
Configuring the BizTalk Adapter for WebSphere MQ v2.0 on the WebSphere MQ Server
Move the installation package that was downloaded from the Web to the WebSphere MQ Server, and click the Setup.exe file to start the installation.
The following screen will appear:
Figure 18 - Installation Screen
Click the Install icon. The welcome screen appears.
Figure 19 - Welcome Screen
Read the warnings, and then Next.
Read the License Agreement, select I accept the License Agreement, and then click Next.
Figure 20 - License Agreement
Enter a full name and name of the organization, and then click Next.
Figure 21 - User Information
Note that the requirements are only 819 KB because only the MQSAgent is being installed. Either accept the default directory or change it using the Browse button. There is only one feature to install, so you do not have to select which features to install. Click Next.
Figure 22 - Feature Selection
Click the Install button to start the installation process.
Figure 23 - Start Installation
The installation will continue.
Figure 24 - Updating System
When the completion screen displays, click Finish to complete the installation.
The installation is now complete and the configuration wizard appears.
Click Next to start the configuration process.
Figure 25 - Configuration Wizard
On the application identity screen, type the name of the user under whom the account will run. Ensure that this user can access WebSphere MQ and is part of the BTS Group on the BizTalk server.
Figure 26 - Application Identity
IMPORTANT: Make sure that you add the BizTalk Service accounts to the COM+ roles in the wizard. The identity of the COM+ application you configure must have read/write permissions to MQSeries queues.
Figure 27 - Role Creation
Click "Next".
Figure 28 - Creating COM+ Application
Click Finish to complete the configuration.
Figure 29 - Completing Configuration
BizTalk Server can now access the WebSphere MQ server by way of the newly installed adapter.
BizTalk Adapter for WebSphere MQ v2.0 Agent on Trading Partner
Alternatively, if there is no MQ Server at Contoso and the trading partner has the following attributes:
| • | Allows for COM+ access through the network to their MQ Server |
| • | Is running WebSphere MQ on a Windows platform |
| • | Allows you to install the MQ Agent on their server |
It is possible to use the BizTalk Adapter for the WebSphere MQ v2.0 Agent on the trading partner. This will allow BizTalk to access WebSphere MQ artifacts as if it were local.
The actual COM+ component must be installed on the trading partner side with network access enabled for COM+ traffic.
The trading partner must also run WebSphere MQ artifacts under different permissions to control access by BizTalk.
In essence, this will allow for push and pull capabilities and Guaranteed Message Delivery, as BizTalk is accessing a full MQ Server.
The following diagram illustrates a high-level architecture of this solution:
Figure 30 - BizTalk Server Adapter for MQSeries Overview
WebSphere MQ Client
When Guaranteed Message Delivery is not a criteria, push or pull notification is required, and the trading partner allows for updates/modifications and creations of queues and queue managers on their MQ infrastructure, then leveraging the MQ Client .NET API is the most feasible and cost-effective solution.
Contoso must understand and agree to a few options prior to using this solution:
| • | The installation and production use of non-supported IBM Service Packs |
| • | A warm failover scenario |
| • | A lowered level of security between Contoso and its trading partner |
The following diagram shows a high level architecture of this solution:
Figure 31 - WebSphere MQ Client Solution Overview
The WebSphere MQ Server exists on the trading partner side and can be used with any operating system that MQ supports. As messages are put into a Transmit Queue, a trigger will call the Windows Application located on the Contoso front. The MQ Channel will contain all the authentication information. To handle the triggering, a trigger monitor is run as a service by using an IBM Support Pack.
The Windows application will then feed the MQ message into BizTalk Server.
To respond to the message, BizTalk will submit an MQ Message to the Windows application and use the MQ Client API to call a "Put" through the MQ Channel onto the trading partner's local queue.
The above solution demonstrates the challenges that Contoso faces:
| • | The MQ Trigger Monitor is maintained using a Windows Service that is installed by a non-supported IBM Support Pack |
| • | The Windows applications that do the "Get" and "Put" to the MQ Queues are installed on each instance of the box. A custom "heartbeat" application must be developed to see when another server in the cluster may pick up the work if the heartbeat were to stop (a warm failover scenario). This failover may not be instantaneous. |
| • | The push scenario requires a modification of the Trigger at the MQ Server location on the Trading Partner side. This trigger will require access to trigger the Windows application on BizTalk to retrieve messages on the WebSphere MQ Queue. This requires that a high level of security be set with the credentials hard-coded in the Windows service. |
WebSphere MQ Connectivity Summary
The following table summarizes the architecture and the requirements:
| WebSphere MQ Connectivity Architecture | MQ Server at Contoso on Win OS | MQ Server at Contoso Trading Partner on Win OS | Contoso Trading Partner allows changes to MQ Infrastructure | Guaranteed Message Delivery Required | Push and Pull notification |
MQ Adapter | X |
|
| X | X |
MQ Adapter to Trading Partner |
| X | X | X | X |
MQ Client |
|
| X |
| X |
WebSphere MQ Tips and Tricks
When replacing SeeBeyond with BizTalk Server, there are various tips and tricks to ensure that WebSphere MQ integrates properly with BizTalk Server.
Some of these tips and tricks include:
| • | Code Page and Application Type ID |
| • | Trigger Monitor as a service |
| • | WebSphere MQ Setup/Configuration |
Code Page and Application Type IDs
This tip is applicable for all three of the above scenarios.
When replacing ICAN on systems other than Windows, strange triggering errors in WebSphere MQ can sometimes occur. One of the most common errors is due to the triggering default setting or setting of the client system's operating system.
This error occurs when applications are being triggered, usually in the application log, when using the MA7K support pack from IBM.
The easiest resolution is to set the APPLType variable to MQAT_WINDOWS_NT.
The following table illustrates the other types of settings that can be used:
| APPLType | Description |
MQAT_AIX | AIX application (same value as MQAT_UNIX). |
MQAT_CICS | CICS transaction. |
MQAT_DOS | DOS client application. |
MQAT_IMS | IMS application. |
MQAT_MVS | OS/390 or TSO application (same value as MQAT_OS390). |
MQAT_NOTES_AGENT | Lotus Notes Agent application. |
MQAT_NSK | Tandem NonStop Kernel application. |
MQAT_OS2 | OS/2 or Presentation Manager application. |
MQAT_OS400 | AS/400 application. |
MQAT_UNIX | UNIX application. |
MQAT_VMS | Digital OpenVMS application. |
MQAT_WINDOWS | Windows client, Windows 3.1 application. |
MQAT_WINDOWS_NT | Windows NT, Windows 95, Windows 98 application. |
MQAT_USER_FIRST | Lowest value for user-defined application type. |
MQAT_USER_LAST | Highest value for user-defined application type |
You must also consider differing operating systems and environments, and data conversion (both character and numeric). The Coded Character Set ID (CCSID) or code page must be set properly for each operating system. Otherwise, any of the following problems can occur with the messages:
| • | Null padding of messages (nulls after each character) |
| • | Doubling in size of messages due to null padding |
| • | Invalid messages or error codes in applications |
The following areas must be verified to resolve this:
| • | Ensure proper installation of client on the Contoso side |
| • | Set the system environment variable MQCSSID= 819 on Contoso |
| • | Ensure that all messages are encoded in the "ASCII" format |
| • | Ensure the MQGET command is set MQMD.CodedCharSetId to 0 to pick up the default CCSID of the QMGR when retrieving messages from Contoso. This ensures that MQSeries knows the correct CCSID to which it must convert. |
| • | MQGMO_CONVERT is set as one of the MQGMO.Options to allow for conversion |
| • | On the Channel definition, ensure the CONVERT(YES) is set |
Trigger Monitor as a Service
This tip is only applicable when using the MQ Client.
The trigger monitor is a daemon that watches for any trigger calls between Contoso and its Trading partner.
With WebSphere MQ on the Windows operating system, a command prompt must be started to initialize the monitor. This would not be acceptable for an automated production environment. Fortunately, IBM provides a support pack (an unsupported support pack) to run this Trigger Monitor as a Windows Service.
The support pack is named "MA7K" and allows the installation of a service to start this monitor.
Please ensure that the proper permissions are set to run this service.
WebSphere MQ Setup/Configuration
This tip is applicable when using the MQ Client or the BizTalk Adapter for WebSphere MQ v2.0 Agent at the trading partner.
This section is applicable only if the trading partner allows modifications to its WebSphere MQ systems. When replacing SeeBeyond with BizTalk Server, there is a matter of switching what WebSphere MQ may push to or BizTalk Server will pull from in terms of live environments.
Where possible, it is ideal to setup new instances of the following on the WebSphere MQ server:
| • | Queue Manager |
| • | Local Queues |
| • | Remote Queues |
| • | Transmit Queues |
| • | Channel(s) and related Trigger Monitoring services |
There are important reasons for setting these instances. The most critical reason is the ability to do a smooth transition between SeeBeyond and BizTalk Server. It is much more simplified, physically and logically, to have BizTalk Server up and running when switching SeeBeyond over. Usually, switching the trading partner application to use a different queue manager and corresponding WebSphere MQ artifacts is a simple soft switch.
The following diagrams depict this scenario:
Other reasons for this deployment transition include ease of backout and troubleshooting. With distinct Queue Managers and artifacts, it becomes trivial to back out the BizTalk server implementation to SeeBeyond and work out any implementation bugs.
In addition, if there is any faulty logic on the trading partner side, and the transactions are still being sent to the SeeBeyond Queue Manager and queues, the information is still being captured on the SeeBeyond queues and may be sent for processing on to the BizTalk Queues.
Conclusion
SeeBeyond offers a suite of integration products which BizTalk Server and its adapter community can replicate and replace. BizTalk Server has many strengths when replacing certain SeeBeyond functionality, which include but are not limited to:
| • | Ease of version upgrade and implementation |
| • | Reduction custom coding required |
| • | Reduction of TCO and maintenance costs |
IBM WebSphere MQ is one of the most commonly used products that connect the SeeBeyond suite to IBM legacy applications.
When replacing SeeBeyond with BizTalk Server, there are several architectural options that allow BizTalk Server to integrate with WebSphere. These include but are not limited to:
| • | Using the BizTalk Adapter for WebSphere MQ v2.0 Agent on Trading Partner |
| • | Using the BizTalk Adapter WebSphere MQ v2.0 on the Contoso side |
| • | Using the standard WebSphere MQ client and the .NET API |
BizTalk Server offers a proven alternative to SeeBeyond by replacing some, if not all, of the functionality offered by SeeBeyond. In a worst case scenario, SeeBeyond may be completely replaced by BizTalk Server by treating SeeBeyond as a black box.
About the Author
Mr. Winson Woo is the Director of Pre-Sales Engineering at Cactus Commerce Inc. In this role, Mr. Woo leverages BizTalk Server and the BizTalk Accelerators, including Cactus GDS Accelerator for BizTalk and the BizTalk Accelerator for RosettaNet to help organizations resolve their B2B and E-Commerce challenges. Mr. Woo is both a Microsoft Certified Professional and a UCCnet/1SYNC-Certified Consultant.
Cactus Commerce Inc. is an e-business software and services provider dedicated to helping companies bring more efficiency to their complex business processes. A Microsoft Gold Certified Partner, Cactus develops and delivers rapidly deployed, cost-effective and extensible GDS and RFID solutions for trading partner integration.
For More Information
The links below provide a more in-depth look at migrating from SeeBeyond to BizTalk Server.