Skip to Content

Prelude:

Owing to the heterogeneous nature of applications in any customer landscape, stickiness and a sense of comfort with the existing applications forms a strong brick wall for a Solution Architect to bang his/her head against. One discussion I had to go through with one of my touch-points a fortnight ago. Though on one hand, you get to meet customers swearing by the powers of XI 3.0, skeptics exist in all nooks and corners of the world who would give an arm and a leg to keep SeeBeyond or WebMethods or MQ Series interfaces alive. Even if it means looking away from the larger scheme of things with the ESA roadmap. Taking the ESA trip with them just doesn’t cut any ice.

The silo approach of an A2A or a B2B scenario overshadows the comprehensive scheme of things to come. An approach I have found to be most useful here is to talk the same language of EAI over here. A comparison of apples and oranges is the best way forward. In this blog, I try to put across some thoughts on how to make a customer wean away from the EAI mindset with a POC approach. This blog introduces SAP XI 3.0 as an integration platform for this customer running R/3 4.6c and R/3 4.7 in different geographies. It takes the current landscape of the client into consideration which includes other middleware/integration technologies.

Current Scenario

The client today uses different EAI tools for the integration requirements of the enterprise. Ready to embrace XI 3.0, they find themselves at loggerheads by comparing the same in terms of performance monitoring, usage of proxies, performance bottlenecks in terms of usage of ccBPM and stability issues arising out of the handling of an XI 3.0 by in a very non-conformist manner. SAP NetWeaver is SAP’s strategic integration and application platform and will be the platform for all of SAP’s solutions going forward. SAP’s solutions will increasingly make use of SAP NetWeaver, particularly in the areas of integration and collaborative processes. Given the fact that the client views its SAP deployment as core, the implementation of SAP XI is a positive step forward and an ideal means to ‘future-proof’ and put in place a strategic platform which will prove to be more flexible and cost effective both from a set-up and an on-going basis.

A suggested way is a proof of concept approach to dispel all myths. The proof of concept is not aiming to replicate the pipeline/replace other EAI tools used by the client, but provides a view as to how Exchange infrastructure can fit in the current infrastructure of the client, meeting the technical requirements. The very paradigm shift of an apple to apple comparison has to be done away with and this is a good way of making XI walk the talk.

Current situation background

– No/Minimal reuse of existing EAI application Interfaces

– SeeBeyond usage & conversions of IDOCs

– SAP Centric Architecture desires SAP Centric solution

– Solution is complex but mostly SAP

– Most interfaces to and from SAP are simple (File to IDOC)

– All of the tightly coupled interfaces are between SAP components or supported by SAP interfaces

– Email, EDI and File Transfer needed and are supported through existing SAP XI components

Proposed Way forward:

– Use a technology stack for the project that is best suited to integrate SAP to SAP systems

– Use the relevant technology to connect SAP systems with Non-SAP systems

– Lay the framework for CAF, MDM, BW Integrations, EP Integrations & usage of WAS (Java & ABAP)

– Create an Integration framework to integrate with the existing SeeBeyond Infrastructure if need be

Options for the client to the way forward:

Option 1. Move now with the existing middleware project, POC of chosen interfaces with XI

Identify a mix of Interfaces that will be developed with say, MQSeries or SeeBeyond& POC with XI. Suffice it to say, the objective is no to say which is better or to do a feature-by-feature comparison of the same. The idea is more towards demonstrating the fact that XI 3.0 is as capable as (if not more) an MQ Series or a SeeBeoynd. Consider the following points:

– Parameter High Volume data/Performance

– Parameter High frequency running interface

– Synchronous & Asynchronous performance mix

– Parameter High Complexity

– Parameter Medium Complexity

– Parameter Low Complexity

– Parameter IDOC/File Interface

– Parameter Non-File adapters

– Parameter re-usability

– Parameter Performance (Load/test/Stress)

– Either source or target system remains SAP

– Compare results & formulate decision/Project plan

Option 2: Go Big Bang with XI with No POC

– Phased approach for an identified business segment as laid down with SeeBeyond/MQSeries specifications, but using XI

– Either source or target system remains SAP

Option 3: Phased approach of the existing middleware project with XI starting with POC

– Start Project kick-off of Existing middleware project with XI for 3-4 months

– Identified interfaces include only Complex & medium

– Either source or target system remains SAP

– Offset POC work lead time with additional days for Existing middleware project

Pure POC Option

– Identify Interfaces of Medium & Complex variety from an identified high-volume business segment

– Build POCs with SeeBeyond & XI for comparison on Option A parameters

A sample case point for XI 3.0

Pre-delivered integration content is the key differentiator of SAP XI when compared to third party middleware vendors. Pre delivered integration content consists of business scenarios, business processes, interfaces, data types and mapping programs that are available in one central integration repository and can be managed/ administered centrally. All SAP solutions(SAP-CRM, SAP-SRM, SAP-SCM, xApps like xRPM) have their integration metadata prepackaged and delivered with the integration repository of XI(The integration metadata of mySAP solutions are available as files and can be imported into XI).

When the systems involved in integration landscape are SAP solutions, building XI repository content is easy and the effort involved is practically non-existent, since integration metadata is available as readymade files which can be imported into XI. This proves to be a key differentiator of SAP XI compared to other third party middleware vendors.

Just as SAP enterprise Portal is destined to be the user-interface layer for all mySAP Business suite solutions and SAP NetWeaver, SAP XI is destined to be the way that you pass message back and forth and maintain certain type of business processes.

Already, SAP XI is playing that role for some mySAP Business Suite solutions. mySAP SRM, for example, uses SAP XI to connect to other applications. And as time goes by, more mySAP Business Suite solutions will make more use of SAP XI. SAP XI plays important role moving information around between SAP NetWeaver components. SAP Master Data Management uses SAP XI to transport the master data it is managing across distributed systems. SAP Business Intelligence, SAP Web Application server, and Enterprise Portal all make similar use of SAP XI as they need.

As time goes on, we should expect SAP XI to do more of what it is doing now – getting deeper into mySAP Business Suite, handling more message types, offering more business content to jump-start the solution to even more problems, automating many B2B relationships, and describing more processes. In the future, the emphasis will be less on the various components and more on SAP NetWeaver as a complete solution, creating services that allows you to model your business and have the flexibility you need, according to the principles of Enterprise Services Architecture. As the model grows, SAP XI becomes more and more of a foundation layer.

For a company planning for EAI implementation the primary challenges are to reducing risk to future upgrade processes and increasing agility to support quicker deployments of new business processes and applications.

A step towards the ESA landscape

The idea is to find a long-term solution that would become part of standards for integration. The ESA architecture aims to embrace this approach:

Promotes “loose coupling” of applications and abstracts the business process from the technical interfaces

Allows for business process oriented interface design and supports the notion of “business messages” based on the business process instead of application data formats

Assures that technical interface components for each application are developed independently of each other and can be reused in multiple business scenarios

Handles interface mapping using reusable technical maps

Provides routing rules based on message content

Leverage Web Services to make it application independent

A Solution Architect’s approach to a POC Business scenario for XI 3.0SPx

A POC Case for B2B Order Import for our fictitiuos organization, Org. A, (Please refer my other blogs for the storyboard) could be the B2B Order Import process to demonstrate the capabilities of XI3.0 in comparison with other EAI tools. Let us walk through the business case for the POC as below:

Note: Let the POC business scenario be simplistic, it does not matter. What matters is a solution approach to a business need that leverages the different applications layer to ensure that the solution is not something that is built in a layer where it should not be built. The Solution Architect needs to avoid the product myopia.

The Business Process consolidation approach first, Keep the EAI approach Out

1. What should be done at the R/3 layer must be done at the R/3 layer. For the POC Business case, process wise, only those orders should be imported into ORGA’s R/3 instance that are validated against the criteria laid down by the Customer Service agents today. Many EAI Consultants have the nasty habit to trying take care of all the business requirements in the EAI tool itself. This can be attributed to a lack of a Solution approach to a business problem. The aim should be to see what can be best segregated as what needs to remain and rectified in the R/3 layer for validations and processing, and build intelligent interfaces around only those areas which warrant a processing in XI 3.0 or any other. All orders that will be imported will have the likeliness to face only three issues:

a). Pricing mismatch (Frequent) : In many cases, the price mentioned in the EDI document does not match with price in the SAP system. In most cases, it happens due to the rounding error. In such an event, each order needs to be manually released for processing. (R/3 layer or EAI? You take a call.)

b). Lead time adjustments (Frequent) : For all rush and full-truck load orders, the shipping dates needs to be adjusted full time. For example, all orders shipped to ORGB and ORGC are rush orders, where the CSR needs to fill the correct shipping date in each line item.

c). Multiple material numbers (Less frequent) : Some wholesale customers such ORGD provide multiple identification numbers for the same item since they supply the item to many end uses. This needs to be corrected manually. (A case for MDM?)

2. When importing new orders, check availability of inventory across alternate shipping locations prior to creating a WIP job. If inventory is available, reserve it and pick it for shipment as soon as possible. (R/3 or EAI?)

3. If any product required for an order is available in inventory, then it should be reserved, picked and shipped right away.

4. In the case of standard pool orders, the orders where the lead time has been specified by the system for orders which are less than a single truckload, It is to be ascertained wither the EDI/Web/Fax customers today, ask CS to ship the product as soon as possible, and whether they supply the “need by date” information on their PO’s. Also, the current process needs to be checked as to whether the CS needs to transmit the “need by date” for Order Import to create a schedule line date in the Sales Order. Again – R/3 or EAI?

5. The same needs to be validated for rush orders or orders with full truck loads where the delivery dates need to be adjusted at each line item level. Today, this is done after referring to the transit table provided by the 3PL company.

For much of the consolidation activities above, it is about handling most of it in the R/3 layer itself, this doesn’t warrant the usage of a middleware application. It would be like using a Cadillac to do some grocery shopping. And this is precisely what a Solution Approach needs to ratify.

The POC XI candidate for the Order Import Program work in SAP R/3today? (Business-wise)

– At the time of SAP R/3 Order Import process, the condition records w.r.t. a customer/Ship to needs to be checked. The state being considered is the ship-to location state.

– If there is a valid tax code existing under ‘EXEMPTIONS” under set up for that customer for that ship-to location, the same is to be picked up and put in the sales Order. The condition record is defined for each and every state wherever the Ship-to state is exempt and a Tax Exemption Certificate number is put in. This has a valid from date, a valid to date and a status.

– Currently, only the Tax Code is checked, not the remaining fields. Therefore, if an order is imported for ORGB to DC or HI or any other state where no exemption condition record is defined, the Sales Order will be taxable & the Tax Code in the Sales Order will show as ‘Sales tax’ in the Order Entry UI. (This will have to go into Tax-Hold in the future)

Now, if an order is imported for ORGB to TX or any other Tax exempt state where an exemption condition record is defined, the Sales Order will be exempt & the Tax Code in the Sales Order will show as ‘Sales tax’ in the Order Entry UI along with the Tax Exemption Certificate that will be picked up from the condition record.

Based on the success of the order import, confirmations have to be sent back to ORGB and notifications have to be sent out within ORGA. If failures happen, one could trigger off human workflows within XI using BPM calling ABAP Workflow for action and siphon off these erroneous orders into a MSSQL database which would be used by another web application for further action.

Ensure that the B2B system should not create a sales order when the “bill to customer” does not have a valid tax certificate for the “ship to” location. Process wise, the Solution Architect needs to ensure that the order should not be imported, and be reported on the existing error reports with an indication describing “invalid tax certificate” or something to that effect. The customer service rep would then cancel the order and ask the customer to re-submit a new order, or direct the product to a distribution center address. Note that the approach being looked at over here is – “Do what you should do at the R/3 layer, do only what is needed to be done at the XI layer.” (Incidentally, the EAI consultants proposed that the entire solution piece be brought into the current EAI application.

While importing the Sales Order into SAP R/3 using XI 3.0 with an IDOC adapter, validating the Ship-To site for a valid condition record for exemptions, check to see the following:

Epilogue:

Let us not get too much into the actual solution. You would note that the POC described above is a very simplistic case. In my opinion, it doesn’t really matter. What matters is the approach you take with the Solution Architecture for the same which will help you strengthen your case for XI to create the roadmap for ESA which needs to be appreciated by the decision makers in ORGA.

One approach: Bottle up the above business scenario with a “take it all into EAI” approach. A trap that many EAI specialists will walk into and go into the comparison mode of the features between XI 3.0 and others. A proxy approach circumventing the adapter route could result in a better performance in the future. Using XI for what it is meant for is another performance booster. Wrapper RFCs to ensure that you processing within the BPM layer could optimize your performance. So would your file sizes during import processing. All these are ignored while taking the pure “EAI” approach to the solution which assist in slotting XI into a zone where it is not meant to be.

The Other approach: Take the layered approach. Keep what is best kept in the R/3 layer. Use ABAP proxies if your landscape allows it. Use wrapper RFCs while using BPM, and you could look at these wrapper RFCs as ideal candidates for web services when you consider reuse. But most importantly, the approach to the POC for XI can be far more effective when you take this approach of segregating the development to ensure a business solution. Of course, there are other factor s as well.

The above POC is an ideal candidate for the ESA domain as well. It is a different debate altogether as to whether web services will compete with EAI or not. The answer is – The two are meant for very different purposes and Enterprise services will only facilitate EAI. Consider the consultant’s approach when you embark on such an initiative. Your feedbacl/opinion would be appreciated.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply