a how-to guide to building xapps: lessons learned from the ... › kmuuid2 ›...

A How-To Guide to Building xApps: Lessons Learned from the FieldKaj van De Loo, Vice President, SAP LapsPeter Kulka, PhD, Solution Architect, SAP AGGoran Stoiljkovski, Solution Architect, SAP AG

Enterprise Services Partner Summit April 18-19, 2006San Francisco, California

Lessons Learned

Demo

Intro

Agenda

Summary

3

What is a Service Oriented Architecture?

Any system that exposes its functionality as services is a service oriented architecture.

In order to realize the benefits of SOA, the service orientationneeds to be everywhere across applications and systems.

The Business and IT infrastructure must be aligned behind the concept of SOA in order for companies to reap all of the benefits of service orientation.

4

Reality Check 2006

Findings and First Conclusions

SOA market hype is on a very high level (e.g. SOA was the focus topic of Gartner IT XPO).

However, the concept inflation is enormous, the concept itself becomes increasingly ambiguous.

Consequently, several studies highlight increasing customer SOA uncertainty.

5

PartnerServices

SAP Composite Apps(incl. UI & analytics)

An Open Platform for ISVs

ISVcomponents

Process Components

OEMPlatform

components

Business Suite

SAP NetWeaverBusiness Process Platform

ISV / CustomerComposite Apps

(incl. UI & analytics)

EnterpriseServices

Repository

Composites

“Integrated into”

Platform

Legacy/3rd Party

“Runs with”Platform

SAPnon-platformcomponents

“Runs/built on” Platform


Lessons Learned

Demo

Intro

Agenda

Summary

7

Product Lifecycle Management for Composites

Testing Go-live Maintenance

ToolsProject Planning Design Development

8

Project Planning

Project Planning

Why are Composite Application development projects different?

How can these differences be handled?

Many new elements are introduced with the new development paradigm:Risk assessment is criticalBringing the project team and environment to the appropriate level of readiness

Software development is fundamentally different for CompositesKeep development teams smallUse an iterative development and phase approach to minimize unknown risksUse an agile development methodology

Key Issues / Recommendations

9

Project Planning (cont.)

Challenge: an agile development in geographically distributed environments

Onsite development and “boiler” room situation creates the right setup

Having functional and technical team together in the same location enables iterative testing and modifications

Define the components / functionalities needed for the composites

Be aware of all dependencies!

Goal: Independence of underlying technology

A successful SOA implementation allows to adopt new technologies, while keeping the old ones as long as they continue to work


10

Tools

Tools

What tools where used and why?

What is the experience?

What are the best practices for using the tools?

Aris – Business Process Modelling

CAF Core – Modelling of objects, No SQL/JDBC coding, Remote persistency, Connectivity to back-end systems, Web Service calls

Stable, provides sufficient functionalities

Model Driven Architecture which maps to the Object Model

Decoupling of Entity Service from Application Service

Composite layer integration with the Web Dynpro


11

Tools (cont.)

CAF UI Patterns – View and edit business objects

Guided Procedures (GP) – Business Process Composition

Provides very comprehensive functionalities

Used for light-weight composite applications

Used to model sub processes that are part of a process

Visual Composer (VC) – applications with no local business logic / persistence

Standard development tools, e.g. NetWeaver Development Studio, Eclipse Web

Tools Project, etc.


12

Design & Architecture

Design & Architecture

What implications does the development of Composite Applications have on the architecture and design?

Start with a phase approach or prove of concept firstValidation mechanism to check technology, team, infrastructure and process readiness

Have a clear strategy/blueprint on using Services within CompositesThrough ESA / define additional guidelines for ServicesImplementation of a Composite Application versus a “traditional” applicationHave a clear idea whether to build new Services, use or extend existing onesChallenge: Granularity of Services (components are either too small or big)

Solution: bring development teams close to businessDefine services outside-in


13

Design & Architecture (cont.)

Design Composite Applications to be back-end independent

E.g. run with 6.40 back-ends and the latest mySAP ERP release

Challenge: A functionality is not available for a specific platform/release?

Possible solutions:

Service enabling according to SAP methodologies and standards

New implementation

Challenge: Service-enabling existing functionalities that are not accessible

E.g. how to expose an ABAP transaction containing SAPGui elements as a service?

Solution: Shield functionality and implement missing parts


14

Development & Implementation

Development & Implementation

Are there any recommendations to use a particular technology?

What about software lifecycle management in general?

General recommendation

Use NWDS for CAF Core / CAF UI Patterns / GP development

Challenge: Keeping business packages in sync

A general issue for all complex applications

Solution: Careful planning and project management


15

Development & Implementation (cont.)

Choice of technologies, e.g.NetWeaver Development Infrastructure versus Open Source (e.g. Maven / CVS)

Keep Open Source, if already in placeMore complex development environments: use NWDI

Web Dynpro/CAF UI patterns versus Open Source (e.g. JSP, JSF, AJAX)Keep Open Source, if already in placeWeb Dynpro versus CAF UI patterns

Web Dynpro may be used for a Wizard-style applicationsCAF UI patterns provide standard functionalities, such as search,

page patterns, predefined configurable patternsWeb Service communication through SAP XI or direct back-end access

UI related service calls: no XI, synchronous callsAsynchronous calls, loosely coupled components: use XI


16

Testing

TestingHow do you perform your test regarding monitoring, functional correctness, performance, scalability, tuning for go-live, measurement or debugging?

Testing depends entirely on the development environment

General recommendation:Use separate systems for testing and development wherever possibleExternal services may be tested through specific parameters, configurationTesting in productive systems might be unavoidable

Configuration of tracks in NWDI can become complex, if a composite consumes many services from other systems / applications

Performance testsThrough 3rd party products, e.g. MercuryExternal services may require special care (system calls may be cached!)


17

Go-live

Go-liveAre there any expected or unexpected issues?

What has to be done for the go-live check?

Setup of the system landscape may take longer than expected (if this is not already in place)

Solution: Careful / realistic planning

The more services/back-ends are consumed the more connectivity issues should be expected

Plan and perform an official hand-over from development to customer


18

Operation & Maintenance

Operation & Maintenance

How does the operation and maintenance of Composites differ from “traditional” applications?

OperationAdministration: Web-based NetWeaver Administrator will replace VisualAdminMonitoring

SAP systems: use the CCMS, which can be integrated into other monitoring infrastructures

Non-SAP systems: use third party frameworks such as BMC, HP, etc.Maintenance (Release and change management)

Challenge: Composites typically depend on NetWeaver components (e.g. CAF-KM integration)Solution: plan upgrades / changes carefullyFix corrections by redeploying of entire archives (to be on the safe side)



Lessons Learned

Demo

Intro

Agenda

Summary

20

Overview

ISV/PartnerSolution

BusinessSolution

Composite Application Solution Integration using Composite Application

Typical scenario: ISV/Partner ↔ SAP

Leveraging the functionality of both

J2EE SolutionEDM

[Educational Data Model]

ERP 2004Materials

Management

Guided Procedure „Course & Event Planning“

Guided Procedure & Web Dynpro UI

Web Service-based integration of fictional ISV Solution EDM

ERP Enterprise Services[based on ESA Preview System]

A Typical ISV/Partner Composite Application Scenario:

21

Composite Application Process „Assign Additional Materials to Event“

Approve additionalMaterials for Event[Purchasing Manager Approval]

Approve additionalMaterials for Event[EDM Manager Approval]

Create Purchase Orderfor additional materials[Purchasing Manager Approval]

Notify Event Planner about approval

Select Course[select course from EDM course list]

Create,View,Edit

Select Event for Course[create Event for selectedcourse in EDM

AssignAdditionalMaterials

Assign additional materials to event[select course from EDM course list]

save

send

Notify Event Planner about denial

deny deny

22

CAF GP

Composite Application „Course & Event Planning“

Architecture

Web Dynpro UI

CAF Core

SAP ERP 2004

ABAP Web Services

XI Interface Proxies

ABAP Implementation

EDM

Java Web Services

J2EE Implementation

SAP XI 3.0Interface Repository

Enterprise ServiceDefinitions

UI Composition

Process composition

Service abstractionxApp Persistency

Enterprise ServiceLayer

Enterprise ServiceImplementation

Generate >

23

Section I: ERP Service Enabling

Section I

Section III: Composite Application Development

Section III

Section II: EDM Service Identification

Section II

Development Procedure

ServiceDefinition

ProxyGeneration

ProxyImplementation

ServiceAbstraction UIWeb Service

Generation

XI ERP / ABAP

ERP / ABAP

ERP / ABAP CAF Core Web Dynpro

EDM ServiceIdentification

J2EE Engine

GP Process Modeling

CAF GP

24

Section I

Section III

Section II

Section I – ERP Service Enabling

ServiceDefinition

ProxyGeneration

ProxyImplementation

ServiceAbstraction UI GP Process

ModelingWeb ServiceGeneration

XI ERP / ABAP

ERP / ABAP

ERP / ABAP CAF Core Web Dynpro CAF GP


J2EE Engine

25

Section I – ERP Service Enabling

DEMO

26

Section III

Section I

Section II

Section II – EDM Service Identification

ServiceDefinition

ProxyGeneration

ProxyImplementation


ModelingWeb ServiceGeneration

XI ERP / ABAP

ERP / ABAP

ERP / ABAP CAF Core Web Dynpro CAF GP


J2EE Engine

27

Section II – EDM Service Identification

DEMO

28

Section II

Section I

Section III – Composite Application Development


Modeling

CAF Core Web Dynpro CAF GP


J2EE Engine

Section IIIServiceDefinition

ProxyGeneration

ProxyImplementation

Web ServiceGeneration

XI ERP / ABAP

ERP / ABAP

29

Section III – xApp Development

DEMO


Lessons Learned

Demo

Intro

Agenda

Summary

31

Summary

Lessons Learned:

Know the differences to “traditional” application development

Start with small projects or prove of concepts

Plan and manage projects very carefully

Use and apply SAP’s ESA blueprint

a how-to guide to building xapps: lessons learned from the ... › kmuuid2 ›...

Documents