Creating A Comprehensive Collaborative Platform With SAP NetWeaver Part III

Creating a Comprehensive Collaborative
Platform with SAP NetWeaver, Part III
SDN Community Contribution

(This is not an official SAP document.)
Disclaimer & Liability Notice
This document may discuss sample coding or other information that does not include SAP official interfaces
and therefore is not supported by SAP. Changes made based on this information are not supported and can
be overwritten during an upgrade.
SAP will not be held liable for any damages caused by using or misusing the information, code or methods
suggested in this document, and anyone using these methods does so at his/her own risk.
SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of
this technical article or code sample, including any liability resulting from incompatibility between the content
within this document and the materials and services offered by SAP. You agree that you will not hold, or seek
to hold, SAP responsible or liable with respect to the content of this document.
2005 SAP AG The SAP Developer Network: http://sdn.sap.com 1

Applies To:
SAP NetWeaver, SAP Enterprise Portal (SAP EP), Knowledge Management & Collaboration, SAP Business
Information Warehouse (SAP BW), SAP Exchange Infrastructure (SAP XI), SAP Web Application Server
(SAP Web AS), SAP Master Data Management, SAP xApps
Summary
This series follows ORGA, a fictional multinational retail conglomerate, as they lay the groundwork for a
service-oriented architecture by leveraging the SAP NetWeaver platform and creating a roadmap for the
future with Enterprise Services Architecture. Part III discusses how to enable key business functions using the
SAP NetWeaver platform, along with Knowledge Management and Collaboration, as a move towards global
standardization and application consolidation and why this is a job best suited for a team that understands
SAP R/3 functionality.
By: Kartik Iyengar
Company: Wipro Technologies (www.wipro.com)
Date: 26 April, 2005

Table of Contents
Applies To:........................................................................................................................................2
Summary ..........................................................................................................................................2
Table of Contents .............................................................................................................................3
Executive Summary .........................................................................................................................4
The Story Board - ORGA Business Background .............................................................................5
The Players...................................................................................................................................5
The Storyboard - As-Is Business & IT Landscape Background.......................................................6
Java or ABAP The ORGA approach .............................................................................................7
SAP R/3 4.6C Upgrade Does it Make Sense?..............................................................................9
The Options ..................................................................................................................................9
The Scenarios.............................................................................................................................10
Indirect Procurement: Phase Out Pure-Play eProcurement Application with SAP EP? ................11
The Key Business Issues ...........................................................................................................12
Discussion Points .......................................................................................................................16
Solution Description....................................................................................................................17
Decision ......................................................................................................................................19
B2B Collaboration: The SAP NetWeaver Way for an SAP XI POC...............................................19
Standardizing Business Processes and Documents in RosettaNet - PIP..................................20
PIP3B2 Business Interface Definition in SAP XI ........................................................................21
Process Flow ..............................................................................................................................21
Variations ....................................................................................................................................22
Epilogue..........................................................................................................................................25
About the Author ............................................................................................................................25

Executive Summary
The SI community is abuzz with SAP NetWeaver initiatives. All the hype is reminiscent of the past, when we
witnessed the B2B bubble. SAP NetWeaver lets us all relive this hype with the expectation for much more.
The "Promised Land" is touted to be in sight and within reach of organizations that are willing to embrace the
panacea provided by SAP NetWeaver. SAP AG and system integrators seem to be having a field day with
this. Organizations are in a whirl with SAP AG already talking about SAP NetWeaver success stories.
The Java community, which was once a pariah to the world of SAP, now sees an opportunity to jump on the
SAP bandwagon who cares about enhancing business functionality rendered by SAP R/3 4.6C? IT
departments of the past are now transforming themselves into powerful business enablers not just being
branded as IT service providers having the power to transform existing business operations with Enterprise
Services Architecture (ESA) or Service-Oriented Architecture (SOA) or Cost Benefit Analyses (CBA) that
lower Total Cost of Ownership (TCO) by providing solutions for integrating Customer Relationship
Management (CRM), Supplier Relationship Management (SRM), and Supply Chain Management (SCM)
applications, along with core Enterprise Resource Planning (ERP) functionality that enhances business
processes beyond the boundaries of the traditional supply chain, creating an ECE (Extended Collaborative
Enterprise) by bringing in business partners into the value-chain of the organization to increase the CCBTTLA
(Confusion Created by These Three Letter Acronyms) for business users.
Although SAP NetWeaver is a technology platform, its benefits only accrue if one views it as an enabler of
business extending from SAP R/3 4.6C in the past, and into the present. System integrators are having a field
day in the mass conversion of talent from other streams in conjunction with SAP AG. All this has a direct
impact on the SAP installed base. Let us see how. Customers have to be extremely choosy about the
implementation teams that would be executing projects for them in the future.
In the previous publication of this series, we saw how Organization A (ORGA), a fictitious organization
running SAP R/3 4.6C, could leverage its existing capabilities to move forward with its SAP NetWeaver
initiatives.
In various workshops that we have been conducting across the globe, the debate repeats itself: ABAP vs.
Java. In this paper, we will evaluate the pros and cons of having an SAP R/3 team drive the SAP NetWeaver
initiatives, in contrast to a team of consultants who understand only Java.
Another question that is repeatedly asked of us is whether to upgrade from an existing SAP R/3 4.6C
environment or not. And, upgrade to what? How? Lets see if we can put forth some creative insights towards
this. We will do so in the context of our storyboard.
Continuing from the last paper, we will now recommend options for an organization to embark upon new IT
initiatives that will lay down the foundation for to create a comprehensive collaborative platform with SAP
NetWeaver. We will also explore a few radical thoughts in this paper that could be useful for any organization
driving initiatives around SAP NetWeaver internally today.
As a move towards standardization of applications, the aim of this storyboard is investigate how to enable key
business functions such as sales, human resources, and plant maintenance using the SAP NetWeaver
platform, along with Knowledge Management and Collaboration, as a move towards global standardization
and application consolidation, and also why this can be best executed by a team that understands SAP R/3
functionality.
A report from Forrester Research, Inc., interestingly, sums it all up in a crisp statement: If all the functions are
SAP-based, SAP NetWeaver is the best solution. If most of the functions are SAP-based, SAP NetWeaver is
the best solution. If none of the functions are SAP-based, SAP NetWeaver is likely not the best solution. In
between "most" and "none," it is a judgment call.

The SAP Unique Selling Proposition (USP) remains its focus on core business processes SAP NetWeaver
rides on the same logic. This says a lot about the implementation team composition.
The Story Board - ORGA Business Background

The end objective of the pilot for the web applications portal is to create a global pilot portal that will enable
key transactions from sales, human resources, and plant maintenance, along with a hybrid solution with
content from ORGA.com and a partial migration of ORGA Intranet.com for the North American SAP instance,
without retiring any of the applications that potentially affect business. It will later be rolled out to Latin
America, Asia-Pacific, and EMEA to be finally syndicated under one single portal for ORGA by facilitating the
phasing out of third-party applications on different platforms and consolidating key business processes onto
SAP.
Along with Knowledge Management and Collaboration functionality, ORGA is looking at deploying key
business functionality through SAP Enterprise Portal (SAP EP) as a strategic initiative to consolidate and
streamline business processes at a global level. With SAP R/3 as the backbone, the key objective of this
strategic initiative is to set the ball rolling towards unifying business processes and the consolidation of all IT
services using a global delivery model ultimately using web services and enterprise services. This global pilot
in turn needs to be furthered by a Proof of Concept (POC) that looks at replacing SeeBeyond as the existing
middleware solution place today at ORGA.
The Players
The four fictitious organizations involved in this pilot are:
1. ORGA: Headquartered in San Diego, CA. The primary business model is to aggregate demand from
large retail stores across the US and Europe, and to try sourcing out for finished goods from the
South Asian Market, or else have demand fulfilled by ORGC. ORGA has three Warehouses two
based in the US (Arlington, VA and Dallas, TX).
2. ORGB: A large retail organization based out of Richmond, VA. The business model works to
aggregate demand from all three distribution centers (which cater to a host of store and online stores)
across the US and Europe. These three distribution centers are located in Bakersfield, CA.,
Gaithersburg, VA., and Peterborough, United Kingdom.
3. ORGC: Based out of China, ORG C is a pure manufacturing organization that takes in aggregated
demand from ORGA and fills demand based on a demand schedule sent every two weeks by ORGA.
ORGB also owns assembly lines in ORGD.
4. ORGD: Based out of Tijuana, Mexico, the business model is to cater to large manufacturers and
accept sub-contracting jobs that are more labor-intensive and require less skill to execute.
Manufacturing in Mexico provides ORGD with a major cost advantage with labor costs.
ORGA is in the process of creating a comprehensive collaborative roadmap in tune with its global focus and
its alignment with SAP NetWeaver as part of the organizational roadmap. We will now use the SAP
NetWeaver framework to convert ORGAs business roadmap into a reality.
For this, ORGA decides to move towards ESA to fall in line with SAP AGs plan by 2007.

The Storyboard - As-Is Business & IT Landscape Background

ORGA is a fictitious organization in the CPG/retail front established way back in 1996. ORGA is in the
business of catering to large retail chains around the US and Europe for manufacturing merchandize items.
These items include cameras, DVD players, and TVs. ORGA uses Siebel for CRM Sales and Marketing, SAP
R/3 4.6C for Order Management and Inventory (for direct goods), and Ariba Spend Management Suite (Buyer
8.x/ACSN/Sourcing 3.x) for indirect goods procurement.
ORGA also uses SAP Business Information Warehouse (SAP BW) 3.0B for all reporting purposes and has
plans to open up limited information to its customers, contractors, and sub-contractors. I2/APO is also being
used for SNP and DP and ORGA is looking at CPFR solution to improve its supply-chain efficiency. ORGAs
business model is to primarily aggregate demand from its customers and have goods manufactured through
their contractor, ORGC (which uses Oracle 11i as their ERP). ORGA also resorts to sourcing demand for
cameras from suppliers in Taiwan and uses the services of a third-party solution provider like WWRE. ORGC
accepts demand forecast from ORGA on a fortnightly basis and manufactures the same.
Depending on the capacity planning requirements and cost/product efficiency, ORGA sub-contracts certain
basis components such as casing and accessories to a subcontractor based in Mexico (for closer proximity to
US and tax benefits) and ships them directly to ORGAs warehouses based in the US and Europe, which
takes care of the basis assembly and stocking. ORGA also uses Ariba spend management for all indirect
material that it procures from its suppliers like Boise Cascade through punch-out, and leverages the
Commerce Services Network to reach all its EDI and low-end suppliers by fax.
ORGB uses PeopleSoft 8.4 SCM and Financials along with HRMS8.8. The Procurement function, demand
aggregation is done using PeopleSoft and all Purchase Orders are dispatched to ORGA for manufacture.
ORGA also uses SeeBeyond, Microsoft BizTalk, Vitria, and Webmethods (as various pilots) to build various
complex interfaces within the organization. Owing to four different products, ORGA realizes the need for a
single vendor to lower TCO and lower licensing costs.
ORGA is also a customer of IBM WebSphere and iPlanet and is using the Application/Web servers provided
by these vendors to develop and host various intranet and Internet portals across the board. Cost is the major
business driver for ORGA to look for a unified platform for all web development activities and to be less
dependant on a host of local vendors providing skills around these areas. ORGA wishes to leverage its
current IT workforce, which comprises largely ABAP. .NET and JAVA skills to reduce manpower cost and
reduce costs further by driving the repetitive and new development activities.
Some legacy applications within ORGA will never be termed sunset applications owing to their usefulness
and political sensitivity. However, it is evident that some functions need to be exposed as globally useable
functions. These business functions need to be more loosely coupled and reused extensively within a private
network of operations.
ORGA has a host of J2EE applications running and wishes to port them onto a singe platform and leverage a
composite application made of all these applications.
ORGA now sees the need to use a single, unified, open platform that is scalable across the organization and
help ORGA reduce TCO.
The following diagram depicts the architecture of ORGA and the way information flows across geographies
over WAN to conduct business as usual.

As-is Information Processing Including ORGA, ORGB, ORGC, and ORGD
Java or ABAP The ORGA Approach

SAP NetWeaver is moving towards the utilization of Java programming, in Java in addition to ABAP/4 (much
to the annoyance of the gods of the ABAP world). Java and ABAP have quite a bit in common. Both or them
use a VM approach; both have more or less equivalent semantics (e.g. object orientation), yet they have a
very different syntax. Java is accepted as a standard in the industry, while ABAP is proprietary and is best-
suited for an SAP ecosystem. Companies that thrive on their internal ABAP factories can continue to extend
applications in ABAP (Although with SAP NetWeaver, we feel there has been more push with Java, to date.
Why else was Web Dynpro programming with SE80 not possible with SAP NetWeaver 04, but was made
available via the SAP NetWeaver Developer Studio? Now, SAP is bringing forth the same in the next release,
along with a soon-to-be-released ABAP/4 editor that brings in the Developer Studio features a long-awaited
relief to ABAPers!)
This means that development at SAP installed base clients would have the additional headache of deciding
on the choice of language for the development of new applications or the extension of existing ones. There is
the choice to develop everything in ABAP, everything in Java, or to use both programming languages.

The choice is based on a host of parameters. Lets explore some of them in our storyboard context:
1. SAP R/3 has been the backbone application at ORGA. Business process consolidation has been
happening over the years at ORGA, which now has a sound ABAP base that extends this knowledge
to SAP R/3. The natural choice is continuing with ABAP as the chosen language for programming
continues.
2. At present, ORGA has been developing Web Dynpros using the SAP NetWeaver Developer Studio
and tilting slowly towards Java, but a key learning has been the creation of various ABAP objects,
such as RFCs and BAPIs on the R/3 side, which were being pulled into the SAP Web Application
Server (SAP Web AS) 6.40 Java stack and were being executed through these Web Dynpros.
3. The added benefit of the above approach is the conversion of these objects into web services and
having them published in the local UDDI registry and using the same through Web Dynpros or SAP
EP (based on the business functionality that was being enabled).
4. The added advantage came with the custom iViews that could be reused. These custom iViews could
be published on SDN (Portal Content Portfolio) as a business package for reuse of these objects
across the instance, lowering development time in the future. Usage of ITS has not been ruled out for
standard business packages for Employee Self Services/Manager Self Services (ESS/MSS).
5. Leveraging ABAP and extending the same with the SAP NetWeaver platform helps keep transports
simple within the ORGA landscape. Same environment, easier to maintain.
6. ORGA will have to invest a huge amount of time and money in its plans to expose the existing
functionality of IS-solutions available via SAPGUI in a browser.
7. Over the years, ORGA has created many custom objects within SAP R/3 4.6C. Standard RFCs and
BAPIs do not exist to render all of the business functionality. Modifications can be done in ABAP only.
The creation of more such custom objects warrant the usage of ABAP.
8. Existing data external to the existing SAP R/3 systems as legacy/third-party applications within ORGA
can be accessed using ABAP as web services. With SAP moving towards ESA, it makes business
sense to ORGA to consume web services for such key functionality being rendered by non-sunset
third-party applications as web services through the ABAP stack.
9. Since ORGA has a host of existing dynpros, the same can be converted into dynpros with the ABAP
stack. The natural choice becomes extending ABAP with the SAP NetWeaver platform.
10. Similar logic can be extended for the usage of ABAP proxies in SAP Exchange Infrastructure (SAP
XI), on SAP Master Data Management (SAP MDM), SAP BW, and other products.
It makes sense for ORGA to continue with the above approach and leverage SE80 in the future to get the
ABAP resources into the Web Dynpro world which will be a far more useful proposition to tap its existing
ABAP base to create and extend applications today. Going forward, ORGA sees this as a logical
transformation of ABAPers into the Java world as well.
Moral of the story: If SAP is the chosen application suite of choice and the backbone application within the
landscape, it makes sense in extending your existing SAP R/3 skills into SAP NetWeaver implementation
teams. The skill base gets decided likewise. Getting a team of pure Java consultants or any other middleware
or pure portal team may not make sense in ORGAs scenario.
It may be noted that there is no point in having an SAP EP/SAP Web AS implementation team that designs
beautiful portals and Web Dynpros if the underlying SAP functionality is not known, or the SAP R/3 business

functionality is not understood. Similarly, an SAP XI implementation team without ABAP knowledge will be
ineffective when it comes to using/building/designing a system based on ABAP extensions, custom functional
modules, or any other ABAP objects.
SAP R/3 4.6C Upgrade Does it Make Sense?

ORGA recently upgraded from SAP R/3 4.6B to SAP R/3 4.6C. The choices that were available for ORGA
were as follows:
Option 1: Upgrade to SAP R/3 4.6C
Option 2: Upgrade SAP R/3 enterprise Ext Set 1.10
Option 3: Upgrade to SAP R/3 Enterprise Ext. Set 2.0
Option 4: Upgrade to SAP ERP Central Component (SAP ECC)
Before arriving at a decision, ORGA contemplated the options listed above.
The Options
Option 1: Upgrade to R/3 4.6C
No choice, ORGA has to upgrade. The cost of SAP R/3 maintenance extension is not a feasible option here
with 4.6B. The question then becomes upgrade to what? Upgrading to SAP R/3 4/6C becomes a viable
option as the support gets extended to 2006. This provides ORGA with enough time for process
consolidations and starting key initiatives on SAP NetWeaver. At this moment, ORGA is more about testing
the waters with SAP NetWeaver; this conservative approach that ORGA has been following to date has
shown positive results in the past.
Options 2 and 3: Upgrade to SAP R/3 Enterprise
Upgrading to SAP R/3 Enterprise would provide ORGA with mainstream maintenance until 2009 instead of an
upgrade to SAP R/3 4.6C until 2006. Since web-enabling of key transactions that can be done with a separate
web application server Java install connected to the SAP R/3 4.6C instance via a JCo connection, and with
the tilt away from ITS-based transactions for ORGA, it is not a matter of grave concern for ORGA. Additional
functionality made available along with direct integration with SAP XI is something that ORGA would consider
sometime later down the line. So the option of upgrading to SAP R/3 enterprise was dropped. The focus in
ORGA today is more on business process consolidation. SAP BW 3.5 is not in the pipeline for ORGA today
as the focus is to use SAP BW 3.1 more and getting the same across to the business users.
Option 4: Upgrade to ECC
Same logic as above applies.
Decision
Upgrade to SAP R/3 4.6C and consolidate business processes along with key SAP NetWeaver initiatives until
market perceives ECC as stable. This provides enough time for ORGA to consolidate key business
processes, embark on key SAP NetWeaver initiatives, phase out third-party and legacy applications, and port

Java applications on a separate SAP Web AS 6.40 SP11 and SAP EP 6.0 SP11, along with phasing out of
SeeBeyond with SAP XI.
The Scenarios
ORGA is an organization that is not purely an SAP shop, but wants to slowly retire all its legacy applications
onto SAP. ORGA is faced with two choices:
Scenario 1: Move all its legacy applications to SAP R/3 and use Web Dynpros to expose key
functionalities as small-group applications led by guided procedures.
Scenario 2: Retain its existing infrastructure and use web services to expose key functionalities
across divisions and weave together composite applications lying down guided procedures.
To-be Information Processing Including ORGA, ORGB, ORGC, and ORGD
The SAP NetWeaver platform is not, in itself, a sufficient reason to upgrade. Most companies will and should
upgrade on the basis of new, critical functionality, but that depends on a host of parameters, of which cost is a
predominant factor.

This may be construed as SAP pushing its own interests on ORGA to use SAP NetWeaver by
recommending an upgrade. Its own return in developing and deploying SAP NetWeaver to its
customers could be far greater than that of ORGA. But in the long run, the ability for SAP to save
money should translate into lower costs for ORGA.
SAP will always make a compelling argument when it comes to using third-party tools to manage
the interaction with SAP data. In the case of ORGA, where SAP is the backbone application,
nobody knows SAP products better than SAP which is reason enough to discuss an upgrade
and initiate SAP NetWeaver projects. This especially holds true for SAP clients where SAP is
used pervasively throughout the organization, across all business functions and spanning
divisions and geographies.
The point that needs consideration is: how to plan for upgrades when and how? What makes
economic sense?
Indirect Procurement: Phase Out Pure-Play eProcurement Application with SAP EP?
ORGA has invested in a best of breed pure-play e-procurement application. mySAP Supplier Relationship
Management (my SAP SRM) may/may not be in the pipeline as the MRO (maintenance, repair, and operating
inventory) spent through such an application still remains fairly low and the business justification is being
worked upon to justify the investments. The same holds true for the existing pure-play e-procurement
application high licensing costs and not enough spend being routed through the application to justify the
continuity of the application within ORGA. Punch-out/round-trip supplier spent is minimal through these and
the use of an existing network; though a critical need, can be done without. Or the usage of the service
network along with an SAP solution is being explored. Before we get into exploring this option in detail, lets
first try to take a look at a few of the existing problems in ORGA (which runs Ariba Buyer 8.x) on top of its
SAP R/3 4.6C application.
As the spending on catalog suppliers is low and the usage of a commerce services network is not so huge
(the actual spend value and volume), ORGA is toying with the idea of a POC with SAP NetWeaver integrated
with IBM Lotus Workflow to see if such an option can be a feasible one. This POC is further strengthened by
the lack of functionality that exists in such a pure-play vendor application that creates a host of process
workarounds. That forms the business case for such a POC.

(Tool: Solution Composer)
The Key Business Issues
Some of the key business issues are detailed below.
Business Issue #1
While faxing purchase orders to suppliers by EDX, fax or any other method, how does ORGA transmit the
terms and conditions, which run into pages, to the existing suppliers? Should ORGA invest in additional third-
party fax software? EDI purchase orders will have the same problems.
Workaround: Modify the purchase order layout to include the following (stated in legal parlance, of course):
If you are an existing ORGA supplier under contract, please refer to the terms and conditions available with
you. If you are not, please get in touch with our buyer for a copy of the terms and conditions. In addition,
ensure that the purchase order layout includes the buyer name and buyer contact information.
Business Issue #2
Application limitations force ORGA to be rigid about purchase order changes. It does not handle
change/cancel purchase orders and push them to the backend SAP R/3 4.6C as needed, and version the

same purchase order with changes; visibility of future versions not been made available to ORGA; huge
technical investment may be needed to meet this now. Discussions with the application vendor.
Workaround: Modify the approval hierarchy in such a way that upon triggering the change/cancel order
process, bring the buyer in the workflow and indicate that it is a change order. Build a manual process around
the same and educate the buyer on the process. So whenever a user changes a PO in the eProcurement
application, an email gets triggered to the buyer, who will manually changes/cancels the PO in the
eProcurement application and the backend mySAP ERP as well.
Business Issue #3
Items available as catalog items being requisitioned as ad hoc requisitions at a higher cost. The idea is to
save costs by streamlining indirect purchasing, not automating inefficient and redundant processes. The
practice of having catalog items being requisitioned as ad hoc requisitions should be stopped, and the
application vendor proposes a contract management application on top of the eProcurement application,
which will require an upgrade to make it compatible. And the same will be made available at a future point in
time and will mean additional cost.
Workaround: Enhance the requisitioning process and UI to do a cross check with a list of catalog items that
may be maintained as a flat file, and then only allow requisition to pass through as ad hoc requisitions that are
validated by the catalog supplier lookup file. So, every time an ad hoc requisition is created, there is an online
validation against each catalog supplier. If a catalog item exists for the same item from a supplier, the
requisitioned is not allowed to proceed further. E.g. Boise Cascade, Grainger, Corporate Express, and Mutual
engraving.
Business Issue #4
Fixed assets/capital asset MRO purchases linked to projects, no way any standard application can handle
this. Custom BAPIs are being called through integration events that run at regular intervals. Add to this
frequent changes to the capital purchase projects with respect to Work Breakdown Structure (WBS) elements
in the underlying mySAP ERP application, and this may lead to discrepancies regarding MRO purchases
tagged to capital projects. A time-based data pull will not help. A requisitioned will have to wait for 12/24 hours
for the correct data to show up.
Workaround: Modify business flow to check the WBS elements and the validity of the projects that have
been pulled into the eProcurement application. Add to this a modification to the workflow to include the fixed
asset manager whenever a capital request gets created. An email would be sent to the fixed asset manager,
who can create/modify the new task/project in the underlying mySAP ERP application if it does not yet exist.
Modify the eProcurement application to allow users to enter all the details related to the fixed asset/capital
purchase, such as project number, task number, expenditure org, expenditure date. The project data from the
mySAP ERP application also data gets pulled into the eProcurement application on an hourly basis.
Business Issue #5
Catalog searches take a very long time to execute, making the requisitioning process an arduous one.
Workaround: Assist the ORGA catalog manager in re-classifying commodities under correct Universal
Standard Products and Service Codes (UNSPSC) categories and create intelligent catalog filters based on
accurate commodity code classifications to enhance search performance, making the requisitioning process a
pleasurable one.

Business Issue #6
Since ORGA is not implementing the P-Card process now, they have a few P-Card suppliers and their
reconciliation is to be handled manually on a month-to-month basis outside the system. But since we are
running in an integrated environment that pushes all POs to the underlying mySAP ERP application, this
doubles our work to have another manual process for the POs coming from suppliers like Boise Cascade or
Grainger. And these are non-punchout catalog items (which forms the majority of the spending).
Workaround: Proposed and made the eProcurement application support this need is most simple for such
suppliers until P-Cards was introduced without having any impact on the business. Their orders were stopped
from being pushed to the underlying SAP R/3 application.
Business Issue #7
There is absolutely no way to monitor spending across various cost centers and put a cap to streamline
processes around allocation usage to help curb spending. If ORGA is to monitor costs based on cost centers
and have a cap on their budgets, ORGA cannot do that with the existing application functionality. Reports are
rudimentary and manual.
Workaround: With the help of key ORGA business users, a monitoring tool for spending, that is an add-on
application to an existing client for zeroing-in on defaulting cost-centers, down to specific people for retraining
and cost cutting, will have to be built. This helps organizations gain more control over spend across various
cost centers. The architecture is the same.
Business Issue #8
Allow the vendors to select and process their invoices over the extranet on their own. After acknowledgement
by Accounts Payable staff, allow SAP and non-SAP users to access their own invoices and approve them.
There needs to a filter based on user type. Send notification to vendors about clarifications and payment
confirmations. Allow AP users to retrieve the invoices from one screen; the current application does not
support it.
Workaround: Vendor Self Service not possible with existing pure-play application. This need warrants an IT
solution workaround.
Business Issue #9
ORGA imports commodities from ORGB, ORGC, and other business partners from different geographical
boundaries, to be re-sold in the US market. Can ORGA have a streamlined process custom built around it?
Right now, all work is manual.
Workaround: Put a process in place to create these as MRO purchases with specific Units of Measure
(UOM) and use partial deliveries to handle them. Have these pushed into your underlying mySAP ERP
application, and resell it using the OM/SD module from mySAP ERP. Handle the inventory transfers within
mySAP ERP manually. This can be resold now and the process that needs to be followed will be governed by
the current mySAP ERP processes.
Business Issue #10
Catalog management becoming too huge to be monitored and maintained with delays in new price lists from
suppliers like Boise, Mutual Engraving, etc. Decision makers became too myopic with application capabilities,
enhancements, and third-party applications

Workaround: ORGA needs to have the catalog manager play a more important role in negotiating with
punch-out ready suppliers, thereby completely eliminating the need for catalog maintenance and ruling out
any spending on development or procurement of third-party applications. But the feasibility of this is being
debated as the moot point becomes: Would the increased use of punch-out/round-trip enabled customers
make ORGA overly dependant on the application vendor?
Business Issue #11
In any approval hierarchy for a requisition, one has approvers and watchers. An approver can be a watcher in
some cases, and vice versa. Opening each and every purchase requisition in my inbox, after logging in, does
not tell you whether you are an approver or a watcher. The application didnt support this. And valuable time
of key approvers was spent on clicking and understanding their role in the PR process. This is an application
limitation.
Workaround: Customize the existing application to show alongside each and every PR in the inbox whether
a person is an approver or a watcher, thereby saving time and effort for key decision-makers.
Business Issue #12
ORGA has a ten accounting segment structure, some combinations may be valid and existing, some may be
valid and non-existent, while others may be invalid. If there is no accounting segment validation happening in
the eProcurement application, many purchase orders will not be reflected in the underlying SAP R/3
application. These purchase orders, though sent to the suppliers as fax or EDI, cannot be pushed into the
underlying SAP R/3 leading to a situation where you have invoices coming in, but no purchase orders to
settle against in SAP R/3.
Workaround: Customize and build a submit hook to validate accounting segments in SAP R/3 real-time at
the time of submitting a requisition and present the buyer with a go no -go decision. Going a step further to
ease usage, for all the accounting combinations that are valid and non-existent, the validation needs to work
to create the same for all future orders as well. This customization will have to be done at both levels the
SAP R/3 layer and the eProcurement application layer.
Business Issue #13
During a product requisitioning cycle, a requisitioner can receive goods, or central receiving can do the same.
This leads to effort duplication one receives, the other approves. With services (which form 57% of all
requisitions in ORGA), it is the other way round. Business needs dictated central receiving to receive all
goods in the dockyard, and the requisitioner to receive all services. There was no need for a receipt approval.
Workaround: Customization. Modify the approval workflow to allow for once the receipt is done, the other
becomes a watcher. This is non-standard application functionality.
Business Issue #14
Consumption orders intra-company orders on MRO items, how can ORGA automate this process flow?
Workaround: Create a dummy supplier in mySAP ERP, pull that into your eProcurement application, host an
internal catalog maintained by the catalog manager and the buyer, and stop these orders from going into your
SAP RP. Do a manual posting in financials for that account code combination as intra-company transfers.
And these items cannot be ordered as ad hoc requisitions, only internal catalog items based on supplier as a
double check.

Business Issue #15
ORGA purchases chemical items as well under this category, and there is no automated process within the
existing application to capture and validate their toxicity numbers from the Dangerous Goods Regulations
(DGR) list. The toxicity number is required for declaration purposes. How do we ensure that all chemical items
that are requisitioned have a toxicity number?
Workaround: A process workaround involving customization for chemical items to be validated against a list
of toxicity numbers against its commodity code. If the item to be procured is a chemical composition, a
requisition should be raised only after capturing the toxicity number at the line item level of the PO. And an
added approver Environmental Manager needs to get added to the approval hierarchy.
Discussion Points
As can be seen from the above, despite the fact that ORGA uses the best-of-breed solution for MRO
procurement, there will always be a host of requirements that will need to be addressed from a systematic
standpoint.
So, some discussion points within ORGA become:
Are such point solutions really worth it? Cannot SAP NetWeaver be used to do away with such
point solutions and allow us to build our own SAP xAPPs using the Composite Application
Framework (CAF) framework?
Of course, there will be many wide-gaps" in the xAPPs applications that one may want to build
based on ORGAs requirements. They will require a huge amount of custom development by a
third-party vendor. But over a period of five years, does a Spend Management Solution, built as
an xAPPs application, make more sense if other products from the application suite of a best-of-
breed solution provider are not on the radar?
Punch-outs/round-trips and catalog maintenance will be the immediate issues. But how can the
use of contracts be leveraged within SAP R/3 to consolidate processes by the ORGA
Procurement Division?
What is the best way forward? Best-of-breed application, SAP xAPPs, or mySAP SRM?
With a commerce solution services now being made available to all SAP and Oracle customers,
does mySAP SRM start making sense? Or can the investment be postponed?
Once ORGA created a business case based on the above business issues, the need for a POC to do away
with such an application and creating a POC with SAP integrated with Lotus Workflow seems logical. Though
this would mean loss of functionality such as punch-out or the usage of the commerce services network and
do away with any specific spend management capabilities that mySAP SRM or any other solution may offer, it
is worth the cost and maintenance of some frequently ordered items in SAP R/3.

Solution Description
Based on the solution-phase classifications listed above, the solution could be designed as shown below.
(The detailed design is being withheld for obvious reasons.)

Existing Proposed Process/Solution Details

Process
Catalog The catalog data can be maintained as part of the Whilst creating requisitions, the requestor will add items to the
Management SAP R/3 material master/maintained as contract requisition cart from the SAP R/3 material data, creating
items. purchase requisitions with reference to a contract.
Approval The approval workflow that is currently executed The approval workflow process may be executed using
Process from the eProcurement solution will be mapped Lotus/Domino or Flow-Brix. The rules and approval chain can
and executed from Lotus/Domino or any other be defined in Domino. Further, the workflow process is from
workflow solution like Flow-Brix (a Powered by the Lotus/Domino end is harmoniously integrated with SAP
SAP NetWeaver application) (if Lotus Workflow EP. This provides personalized information on the business
can be looked upon as the approval engine processes requisitions through the approval process and
integrated with SAP EP). creation of purchase order. The same applies to Flow-Brix as
well.
Requisition Requisitions will be created in SAP R/3 in the Requisitions can be created using the custom-built application
proposed solution thereby facilitating the removal in SAP R/3 using Adaptive RFCs
of the existing eProcurement system.
Purchase Orders The purchase orders as earlier will be created in The only change is the trigger point of the PO create process
SAP R/3. will be from Lotus/Domino or Flow-Brix.
Vendor Purchase This solution will be portal-based. This application will create purchase orders based on the
Order material master present in SAP R/3 with contracts.
Vendor/Supplier This solution will be built as a portal-based Web This solution would provide the vendor/supplier to access the
Self Service Dynpro solution. application via SAP EP and view applications like vendor
information, invoicing information/status, bank information.
As can be seen from above, ORGA is in a position to leverage its investments on SAP NetWeaver to create a
process workaround on its spending management area where the catalog spending is low, punch-outs are
near non-existent, and the use of a commerce services network can be done away with. And of course, there
are other business considerations.
And now one sees pushback in the market from Ariba, as just recently, On April 26, 2005, Ariba announced
that it was opening up its Ariba Supplier Network to companies who are using eProcurement products from

competitors like SAP and Oracle. The move is said to shake up the eProcurement and eSourcing market.
Ariba gives up its competitive advantage of having the largest network of pre-enabled suppliers for customers
of its Ariba Buyer eProcurement product, benefiting SAP and Oracle, whose sales of eProcurement products
have been handicapped by not offering a comparable supplier network.
On one side, Ariba can now go further in monetizing the value of the Ariba Supplier Network, building a new
revenue stream while threatening smaller supplier networks.
On the other side, if punch-out capabilities and catalog management are not a necessity in ORGAs case, it
may as well find a workaround without any eProcurement solution.
And as can be seen from above, the skills that ORGA would need to execute such an activity will HAVE to
have SAP R/3, ABAP/4 extending to SAP EP, SAP XI, and SAP Web AS. Needless to say, pure-play SAP
NetWeaver consultants with no SAP R/3 or ABAP background will be of no use here.
The decision to embrace SAP NetWeaver will be driven by a corporate viewpoint on extend versus build.
Decision
ORGA decided to leverage its existing ABAP skill base and extend it to SAP NetWeaver, along with a chosen
system integrator to put together a team that extends its ABAP knowledge to SAP NetWeaver and the
eProcurement solution experts. No pure-play SAP NetWeaver consultants here.
B2B Collaboration: The SAP NetWeaver Way for an SAP XI POC

ORGA plans to do a POC with SAP XI 3.0 to replace its existing middleware solution in the long run. This
ORGA POC would be to test out the complete, out-of-the-box solution to enable cross-enterprise processes
via RosettaNet Partner Interface Processes (PIPs), including the technical adapters and application-to-
interface mappings needed to realize true, automated bidirectional B2B communication. RosettaNet 3B2 PIP
processes are used for the Advance Shipment Notification business scenario to enable communication to and
from your backend systems with those of your customers and partners.
ORGA needs to use advanced business process management (BPM) capabilities to design, execute, and
monitor the order-to-invoice process across applications and systems within the ORGA system landscape.
The POC will kick off with the SAP XI installation for ORGA using SP11 (or SP12, based on availability).The
business blueprint phase will involve identifying the ORGA 3B2 business process currently modeled on the
existing SeeBeyond installation. The workflow process and database tables to be integrated to SAP XI will
also be identified and the integration scenario will be modeled. In the realization phase the identified
interfaces will be developed using the RNIF adapter, data lookups will be carried out using JDBC, and
workflow integration will be carried out.
In the long run from an SAP NetWeaver roadmap perspective, a phased approach to implement SAP XI 3.0
at ORGA is being recommended. The phased approach will begin with demonstrating the Proof of Concept
for a hybrid mix of scenarios. Once the proof of concept is established, identify some of the integration points
with SAP products and execute a project to replace the same for ORGA.
Since there are many non-SAP systems integrated using other middleware, it is not recommended replacing
that middleware with SAP XI; rather, use SAP XIs capabilities of interacting with middleware and complete
the integration wherever it is required.

A quick run-through - Powering the business package, SAP NetWeaver:
Manages the RosettaNet PIP process definitions and the RosettaNet Implementation Framework (RNIF)
2.0 adapter.
Houses the integration repository, where the order-to-invoice business scenario, processes, and
mappings are managed, including the integration directory, where the technical characteristics of
partners, such as party identification and collaboration agreements, are managed.
Drives the integration and adapter engines, RNIF 2.0 adapter, for example, and provides a framework for
partner messaging, queuing, and B2B security signature and encryption handling.
ORGA adopted RosettaNet PIP in an industry business scenario:
Standardizing Business Processes and Documents in RosettaNet - PIP
A Partner Interface Process (PIP) specifies the business documents that are exchanged within a business
process, the sequence in which the messages are exchanged, and the physical attributes of the messages
that define the quality of service. The business documents and the exchange sequence are specified in XML.
Today, more than 50 PIPs have been validated by actual implementation between two trading partners, and
are freely available for download by the public.
PIP defines the following:
Roles for the trading partners that use the business process are defined. For example, PIP3B2,
Advance Shipment Notification, defines the roles "Buyer" and "Seller."

The business process is defined in terms of the business activities it requires. For example, in
PIP3B2, the business activities are Advance Shipment Notification and Process Advance
Shipment Notification/Send General Acknowledgement.
The messages (business documents) exchanged between the roles are called "action"
messages. The Advance Shipment Notification business activity sends a Shipment notification
Action Message from the Seller to the Buyer. The Buyer activates the Confirm Shipment
notification Business Activity and sends a Shipment notification Confirmation Action Message to
the Seller. The PIP defines the content and format of the action messages in XML.
The sequence in which these messages is sent and the quality of service attributes for the
message exchanges, such as time to respond, authentication, and number of retries in case of an
unsuccessful message transmission, are defined.
PIP3B2 Business Interface Definition in SAP XI
SAP XI provides preconfigured out-of-the-box content for RosettaNet 3B2 PIP process. The technical details
are as follows.
In the SAP XI Integration Repository, the standard template for 3B2 PIP interface and business process can
be found under the Software Component version ROSETTANET in the namespace
http://sap.com/xi/RosettaNet/PIP3B2_V0101." This contains the template for the 3B2 data structure (3B2
DTD) as defined by the RosettaNet 1.0 specification.
In another software component version called ROSETTANET R3 the SAP XI integration content for RNIF
can be found with details of the integration scenarios to be defined for RNIF 3B2 process, depending on the
roles involved in the process. There is a pre-built integration scenario, Process Advance Shipment
Notification with an SAP R/3 MM system configured as the receiver.
Process Flow
Role as Buyer
In this pre-built buyer scenario provided with SAP XI, the IDoc DESADV.DELVRY03 in the MM system will
be executed once a notification in RosettaNet message protocol format is received by the RNIF receiver from
the partner system. This in turn makes use of the pre-built mapping,
Pip3B2AdvanceShipmentNotification_DesadvDelvry03 to convert standard RNIF 3B2 ASN structure
PIP3B2AdvanceShipmentNotification into the IDoc structure.
The pre-built communication channel template can be used to build an instance of an RNIF receiver
communication channel using transport protocol, HTTP1.1 and RNIF 2.0 in single action asynchronous
request mode. The URL of the partner application has to be provided in adapter configuration for the
message flow to happen from the partner environment. Specify the outbound URL on the partner system as
follows for this purpose:
http://<host>:<port>/MessagingSystem/receive/RNIFAdapter/RNIF
The following need to be configured in sender order for ASN message to be sent from RNIF to the partner
system:
Configure Party
Configure Service

Service Name: - PIP<PIP Code>_<PIP Version>_<Partner Role>. For example:

PIP3B2_V0202_Seller where 3B2 is the PIP code, V02.02 is the version and Buyer is the
partners role
Create the RNIF communication channel
Receiver determination
Interface determination
Sender agreement
The details for these configurations will depend on the partner to which the ASN message is being sent out.
This integration can also be looked at from the other side, where the role of ORG A is of a Shipper. The
scenario remains more or less the same except for senders and receivers, which results in change of the
triggering and receiving points.
Variations
How do you ensure that manual approval processes come into picture with the integration happening
between multiple systems?
Human Workflow
Within SAP NetWeaver, separate tools can be used to define integration processes and human workflow
processes.
Integration business processes are:
Message-based
Interface-focused
Inter-application
Have no support for human interaction
Enabled with SAP XI
Human workflow processes are:
Object-based
Human-focused
Intra-application
Have no support for mapping, routing, or message transformations
Enabled with SAP Web AS
However, most automated business processes involve a combination of the above two.

There are two ways by which we can demonstrate integration between SAP XI and external workflows.
1. By integrating SAP XI with an SAP R/3 workflow
2. By integrating SAP XI ccBPM business process with human workflows of SAP EP.
For the POC we recommend approach (1), with which we can build an integration scenario demonstrating
SAP XI integration with an SAP R/3 workflow. This can be carried out by using SAP XI to send a message to
SAP R/3 to trigger an SAP workflow.
However, from an SAP NetWeaver roadmap perspective in the long run, in order to achieve the integration of
integration business process and human workflow, ORGA would need to use Universal Work List and ad hoc
workflow features of SAP EP.
To automate the complete business process, different workflow engines can be used. There is clearly an
overlap in how much of the business process takes place in one workflow engine or the other, and this needs
to decided at the beginning of the project.
ORGA has taken a conscious decision of not having SAP XI being looked at as a replacement middleware
application, owing to the high investments on other middleware technologies and the existing relationship with
IBM and Microsoft.
SAP XI Strategy
The strategy with SAP XI is simple:
1. In the long run, for all applications interfacing with SAP applications, use SAP XI.
2. For all other B2Bi/EAI interfaces, use existing middleware BizTalk/SeeBeyond/ MQ Series (ORGA
being an IBM and Microsoft shop).
3. Leverage ESA & web services for all middleware technologies.
4. Initially, SAP XI will be used for integration with other non-SAP applications as well from a POC
perspective.
ORGA Business Need
The ORGA business need is as follows:
Option to use any other BPM tool like FlowBrix to leverage the investments made in this area with
SAP Solution Manager for cross-component BPM within SAP XI 3.0.
Open system architecture for CAF, lays the ground for future xApps.
Supports different data formats that will be a need at ORGA.
XML support, standards-based architecture to perform tasks such as intelligent routing.
Allow easy and non-disruptive addition of new services and processes.
Easy and scalable to integrate with any SAP application (MDM, MI, EP, KM, BW, etc).
Business Process Management - Business Process Engine to monitor the Business process
implemented.

Key Areas of Concern
The key areas of concern that SAP XI is being used to address are as follows:
A business system is connected to the integration server using the IDoc adapter, which exchanges
IDocs with the business system. (IDOC Adapter)
A third-party business system is connected to the integration server using the plain HTTP adapter,
which exchanges XML messages using plain HTTP with the business system. (Plain HTTP Adapter)
A third-party (or legacy) system is connected to an integration engine using the file adapter, which
exchanges text files with the third-party system. When reading a file from the third-party file system,
the file adapter transforms this file into an XML message for further processing by the integration
engine. (File adapter)
A third-party or legacy system (or simply a database) is connected to an integration engine using the
JDBC adapter, which accesses database content using JDBC. When reading database content, the
JDBC adapter creates an XML message from this data and sends it to the integration engine for
further processing. (JDBC Adapter)
SOAP/RNIF, Java, and ABAP proxies will be piloted out shortly.
SAP XI PCK will be used for other divisions within ORGA and the same may be piloted out for ORGB,
ORGC, and ORGD.
The end objective is to standardize all application integration with SAP systems with SAP XI and non-SAP
systems with Biztalk or SeeBeyond. This initiative is being looked at from a non-replacement mode to avoid
any vendor clashes and to provide ORGA with a clear idea on the skill set of the SI community.

Epilogue
This article presents an approach an organization can take with SAP NetWeaver. This is only ONE
perspective, one school of thought. Many more perspectives exist and we shall keep putting these forth to the
SDN community. If you would like any aspect to be highlighted, or provided for in detail, please write to us.
Thank you for reading the Creating a Comprehensive Platform with SAP NetWeaver series. We hope you
find this series useful.
About the Author
Kartik Iyengar is a solution architect who leads all SAP NetWeaver initiatives at Wipro
Technologies (www.wipro.com). Kartik has more than 11 years of experience in consulting,
solution architecting, and program managing implementations across SAP R/3, Oracle
Applications, Ariba Spend Management Suite, PeopleSoft, bespoke application
development, and integration technologies. Before joining Wipro Technologies, he has
worked with IBM Global Services and DHL WorldWide Express. The SAP NetWeaver Group
in Wipro comes under the Global SAP Practice within EAS (Enterprise Application
Services). He can be reached at Kartik.iyengar@wipro.com.
***

Creating A Comprehensive Collaborative Platform With SAP NetWeaver Part III

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Creating A Comprehensive Collaborative Platform With SAP NetWeaver Part III

Hochgeladen von

Copyright:

Verfügbare Formate

Creating a Comprehensive Collaborative

Platform with SAP NetWeaver, Part III

SDN Community Contribution

Disclaimer & Liability Notice

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 1

By: Kartik Iyengar

Company: Wipro Technologies (www.wipro.com)

Date: 26 April, 2005

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 2

Table of Contents .............................................................................................................................3

Executive Summary .........................................................................................................................4

The Story Board - ORGA Business Background .............................................................................5

The Storyboard - As-Is Business & IT Landscape Background.......................................................6

Java or ABAP The ORGA approach .............................................................................................7

SAP R/3 4.6C Upgrade Does it Make Sense?..............................................................................9

The Options ..................................................................................................................................9

The Key Business Issues ...........................................................................................................12

Discussion Points .......................................................................................................................16

B2B Collaboration: The SAP NetWeaver Way for an SAP XI POC...............................................19

Standardizing Business Processes and Documents in RosettaNet - PIP..................................20

PIP3B2 Business Interface Definition in SAP XI ........................................................................21

Process Flow ..............................................................................................................................21

About the Author ............................................................................................................................25

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 3

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 4

The Story Board - ORGA Business Background

The four fictitious organizations involved in this pilot are:

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 5

The Storyboard - As-Is Business & IT Landscape Background

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 6

As-is Information Processing Including ORGA, ORGB, ORGC, and ORGD

Java or ABAP The ORGA Approach

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 7

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 8

SAP R/3 4.6C Upgrade Does it Make Sense?

Option 1: Upgrade to SAP R/3 4.6C

Option 2: Upgrade SAP R/3 enterprise Ext Set 1.10

Option 3: Upgrade to SAP R/3 Enterprise Ext. Set 2.0

Option 4: Upgrade to SAP ERP Central Component (SAP ECC)

Before arriving at a decision, ORGA contemplated the options listed above.

Option 1: Upgrade to R/3 4.6C

Options 2 and 3: Upgrade to SAP R/3 Enterprise

Option 4: Upgrade to ECC

Same logic as above applies.

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 9

To-be Information Processing Including ORGA, ORGB, ORGC, and ORGD

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 10

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 11

(Tool: Solution Composer)

The Key Business Issues

Some of the key business issues are detailed below.

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 12

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 13

Business Issue #10

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 14

Business Issue #11

Business Issue #12

Business Issue #13

Business Issue #14

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 15

Business Issue #15

So, some discussion points within ORGA become:

2005 SAP AG The SAP Developer Network: http://sdn.sap.com 16