functionality differences between XI and other middleware

[Former Member]

Can any one tell me what are the advantages and disadvantages of XI over other middleware and what functionality is missing in XI right now compared to other middleware?

Thanks,

Anika Narayan

[former_member91687 · Accepted solution]

Hi Anika,

Lots of discussions on this one , have a look:

Cheers,

Chandra

[Former Member · Accepted solution]

Good question

From experience and discussions with other customers have yielded probably interesting questions on XI's capabilities, some of the questions on its abilities would

1) Failover mechanisms and clustering capabilties-Does it Involved a downtime- Answer is YES which is a problem for us in convincing customers of XI's ability as a stable middleware..Its evolving so have to put up with it.

2) XI-XI communication is primitive..is not native performed as in say webmethods/TIbco..Bridge mechanism is missing..Now its either HTTP/SOAP/JMS for communication.

3) Needs more integrated mechanisms between BPE and Mapping engine..I would say other middlewares score again on this front.

Thr are quite a lot more..........but probably can be blogged than put on a forum

[Former Member]

Hi Anika,

Here are the advantages from my point of view.There are lots of advantages but to list a few :

1.Connectivity: Packaged Application adapters, Middleware adapters, Adapters to file system, mainframes and databases. Availability of custom adapters.

2.Transformation and mapping tools

3.Content based routing: Routing of data based on message content

4.Business Process Composition: Component model for BP composition as well as support for control and data flow modeling.

5.Message Warehousing: Message persistence for store and forward as well as support for message mining and message archiving

6.Business Process monitoring: Real time monitoring of processes as well as components involved in BP.

7.Compose and execute Business processes that invoke WebServices

8.Dynamic reconfiguration of Business processes: Flexible to support reconfiguration of business process with no or minimal intervention

9.Multi language support: Component development, code generation support in various programming languages

10.J2EE, .Net and WebServices support

11.Performance and scalability

12.24 X 7 reliability and security

13.Easy Integration with SAP products & components (RFC, IDOC, Proxy).

14.Synchronous & Asynchronous communication possible.

15.Mapping etc possible to accomplish in Java. Platform independent Java components.

16.Big range of adapters for different technologies / tools (SOAP, Mail, JDBC, CDIX...)available in standard or offered by other companies (EDI e.g. by Seeburger).

17.Process functionalities inside XI to modify content in the communication channel on own defined rules fpr business purposes.

For more information about XI, Please go through this link:

https://websmp201.sap-ag.de/xi

Regards,

Abhy

[Former Member]

Anika,

Some of the urls where you can get some info about the middleware products XI, Biztalk, Webmethods etc are:

BizTalk or SAP XI

I have experience with both SAP XI 2.0 and 3.0 and just finished a BizTalk

2004 training.

There are some similarities between both tools:

- both have a non-distributed hub-and-spoke architecture

- both support the export/import of BPEL

- both use iWay to provide them with extra adapters

- both strongly focus on XML schema's to define messages

- both have fine file adapters capable of handling different types of record

structures

- both tools don't allow debugging of flows and processes

 (well, BizTalk does support process debugging buth is pretty clumsy)

- both are new(er) players in the EAI market and lack the history (and e.g.

large sets of adapters) as opposed to IBM/Tibco/WebMethods/...

- SAP XI 3.0 is just GA and BizTalk 2004 also seems to have been released in

quite a hurry (e.g. incomplete docs)

Differences:

- SAP XI is largely based on J2EE (+ proprietary ABAP)

 while BizTalk 2004 is completely built on .Net

 (as opposed to its predecessors that were COM based)

- XI comes with more (technical) adapters in the box:

   POP: Biztalk only supports SMTP

   JMS: Biztalk only supports MSMQ and MQSeries

   JDBC: BizTalk can only talk to SQL Server

- BizTalk has support for EDI, which is completely lacking in SAP XI

- SAP XI allows the use of XSLT but prefers its own event-driven (but

somewhat limited) message mapping solution

 (the use of a 3rd party XSLT graphical mapper like Sonic StylusStudio is

an alternative)

 BizTalk uses XSLT as its mapping technology and comes with a full blown

XSLT graphical mapper

- SAP XI is more resource hungry than BizTalk

- SAP XI is more complex and has a steeper learning curve

Regarding the choice between BizTalk and SAP XI:

- if you are strongly focused on Microsoft and in particular .Net, go for

BizTalk;

 BizTalk 2004 actually generates .Net code underneath

- if SAP represents a major part of your IT landscape, go for XI

 you will get it anyway as SAP evolves to its cross application solutions

- there are little or no EAI products based on .Net

 so it is more likely to find 3rd party complementary software for XI

If the vast majority of your integration is with SAP, I would strongly

recommend you take a look at XI 3.0, especially given the volumes you

have described. Its much improved from 2.0 and has a lot of pre built

integration mapping into SAP out of the box, basically saving you a lot

of time.  

I've seen plenty of scenarios where WIS/WBI, Biztalk and XI have all

worked great, and plenty where none of them were the best choice. Am

sure most on this list have similar stories.

Is your group doing mainly .Net, Java/Websphere or perhaps even mainly

ABAP development? That might be another factor in picking a tool. And as

always cost and your longer term architecture plans should drive the

decision too.

At present yes, but we have an option of using IBM WIS. At the moment we are evaluvating only for BizTalk and SAP XI.

We are using Biztalk to integrate SAP with legacy system (IBM VSE/CICS)

through :

- BAPI

- IDOC receiving and sending

- Batch file : FTP / XCOPY

That works well; we develop a connector based on .net SAP connector (from

SAP) for the BAPI calls, and implement an integrated error management.

Iway and others sell BAPI / SAP connectors that you can integrate with

Biztalk without development.

We use Biztalk Adapter for SAP (from Microsoft) to receive IDOC from SAP,

coupled with the DCOM SAP connector to manage tRFC connections.

We encapsulate Microsoft component to add traceability to send Idoc.

We have at about 70 types of flows and up to 11000 instances of flow per

day. (lot of different flows, but no high volume)

About legacy system, we use FTP and HIS (Host Integration Server) to have a

CICS connection with Biztalk.

All this system is based on Biztalk 2002 and MSCS clusters (one for Biztalk,

and one for SQL).

We probably start a migration to Biztalk 2004 in 2005, Biztalk 2004 have

many enhancements compared to Biztalk 2002 which is not a mature product.

(... and needed many additional components to meet the system requirements:

availability, "manageability", "traceability" all Operation Administration

Maintenance features).

I have no experience with SAP XI.

Your choice depends on what you have in front of SAP to integrate: legacy

systems (CICS), FTP exchange, EDI, other ERPs, MES. But also what is the

purpose of the EAI system in our architecture: only SAP integration or more

?

We typically have some flows as following :

- source document : fixed length flat file or csv

- destination doc : IDOC ORDERS05 to SAP

Or

- source document : IDOC INVOICE

- destination doc : flat file (fixed length format)

Biztalk has tools to :

- generate XML schema for the IDOC (good tool)

- build the XML schema related to the flat file (good tool)

We have then to do the mapping between the source doc to destination doc, we

use directly pure XSLT rather than the biztalk mapper (pretty but not

convenient for complex mapping and global efficiency and maintenance), we

prefer XML spy or other XML/XSLT editor.

(note : Biztalk flows can be implemented without workflows or business

processes.)

If you have already Biztalk and you don't have to buy it, you should use it

(if Biztalk 2004) if not use another way.

Limitation to be known:

The reception of IDocs by bIztalk could be done through a MSMQ and Biztalk

Adapter for SAP (Interchange configuration in SAP, this is transactional but

the max size is limited to 4MB)

If you have documents with a too big size they will be marked on error in

SAP. (tRFC problem)  

The bypass will be to remove all the empty segments from the IDOC in SAP,

this is a classic way to proceed when sending IDOC from SAP whatever the

EAI.

MSMQ has a 4MB limitation on Windows 2000, this size limitation no longer

exits on Windows 2003.

The reception of IDocs by Biztalk could be also done through file, in that

case you have no size limit, but this is not transactional.

Another point is error management, in production you will face IDOC

integration (from business point of view) problems in SAP. The IDOC error

management is done by SAP only, using Biztalk you only know that data

structures and transfer are correct.

If SAP XI offers an integrated error management that could be a real

advantage.

JMS adapters with Biztalk that could be fun, that exists but I have no

experience.

---Satish