sappress xApps.pdf

8/13/2019 sappress xApps.pdf

1/38

Jo Weilbach, Mario Herger

SAP xAppsand the Composite Application

Framework


2/38

5Contents

Contents

Preface 9

Acknowledgements 11

Introduction 13

1 SAP xAppsBasic Principles 17

1.1 Market Situation and Opportunities ............................................................ 171.2 The Evolution of Business Applications ....................................................... 20

1.2.1 Traditional Development and Architecture .................................... 211.2.2 Web Services, Service Oriented Architecture (SOA) and

Enterprise Services Architecture (ESA) ........................................... 231.2.3 Composite Applications .................................................................... 30

1.3 Characteristics and Definition of SAP xApps .............................................. 331.3.1 Composite Applications from SAP .................................................. 331.3.2 SAP xApps .......................................................................................... 351.3.3 Properties and Requirements of SAP xApps .................................. 361.3.4 SAP Composite Application Framework ......................................... 381.3.5 Advantages of a Close Integration with SAP NetWeaver ............. 39

1.4 The Developers of SAP xApps ........................................................................ 401.4.1 SAP as a Developer of SAP xApps ................................................... 401.4.2 The SAP xApp Partner Program ....................................................... 40

1.5 Ideal Procedure for the Creation of an SAP xApp ...................................... 421.6 First Implementation Examples ..................................................................... 45

1.6.1 SAP xApp Resource and Portfolio Management (SAP xRPM) .....

461.6.2 SAP xApp Emissions Management (SAP xEM) as an Exampleof a Partner xApp ............................................................................... 49

1.7 Possible Decision Criteria for Developing an SAP xApp or a CustomComposite Application .................................................................................... 511.7.1 Business Criteria ................................................................................. 511.7.2 Criteria Determined by the Characteristics

of the Business Process ..................................................................... 511.7.3 Criteria Determined by the Type and Source of the Information 53


3/38

Contents6

2 The Architecture of SAP xApps 55

2.1 SAP NetWeaver Overview .............................................................................. 552.2 SAP NetWeaver Components ........................................................................ 56

2.2.1 Application Platform ......................................................................... 572.2.2 Process Integration ............................................................................ 612.2.3 Information Integration .................................................................... 642.2.4 People Integration ............................................................................. 742.2.5 SAP Solution Lifecycle Management ............................................... 80

2.3 SAP Composite Application Framework ...................................................... 812.3.1 Vision ................................................................................................... 812.3.2 Comparison ........................................................................................ 822.3.3 SAP Composite Application FrameworkPrinciples .................... 852.3.4 General Structure of the CAF ........................................................... 86

2.4 Architectural Model of SAP xApps ................................................................ 94

3 The SAP Composite Application Framework 97

3.1 Introduction ...................................................................................................... 973.2 Scenario xFlights .............................................................................................. 98

3.2.1 Scenario .............................................................................................. 983.2.2 Modeling ............................................................................................. 993.2.3 Building an Application in the Classical Way ................................. 102

3.3 Architecture and Tools of the SAP Composite ApplicationFramework ......................................................................................................... 1053.3.1 General Remarks ................................................................................ 1053.3.2 Installation .......................................................................................... 1093.3.3 Life Cycle of a Composite Application ............................................ 1093.3.4 Composite Application Project ........................................................ 1103.3.5 CORE ................................................................................................... 112

3.4 External Services ............................................................................................... 1143.5 Entity Service .................................................................................................... 115

3.5.1 Introduction ....................................................................................... 1153.5.2 Modeling ............................................................................................. 1163.5.3 CORE Services .................................................................................... 1223.5.4 Persistence .......................................................................................... 1263.5.5 Generation, Build and Deployment ................................................ 1323.5.6 Testing ................................................................................................. 1343.5.7 Authorizations .................................................................................... 135

3.6 Application Services ......................................................................................... 1383.6.1 Introduction ....................................................................................... 1383.6.2 Modeling ............................................................................................. 1393.6.3 Coding Examples ............................................................................... 1423.6.4 CORE Services .................................................................................... 143

3.6.5 Generation, Build, Deployment and Testing .................................. 143


4/38

7Contents

3.7 User Interface ................................................................................................... 1443.7.1 Web Dynpro ...................................................................................... 1443.7.2 Patterns ............................................................................................... 1453.7.3 Web Dynpro Foundations ................................................................ 1553.7.4 xFlights Example ................................................................................ 1563.7.5 Special UI Elements ........................................................................... 159

3.8 Process Modeler ............................................................................................... 1623.8.1 Introduction ....................................................................................... 1623.8.2 Guided Procedures ............................................................................ 163

3.9 Business Intelligence Integration .................................................................. 1663.9.1 Types of Integration .......................................................................... 1663.9.2 Extraction ........................................................................................... 1673.9.3 Display ................................................................................................ 1723.9.4 Retraction ........................................................................................... 1733.9.5 Navigation .......................................................................................... 1733.9.6 Guided Procedures ............................................................................ 175

3.10 Knowledge Management Integration .......................................................... 1753.10.1 TREX .................................................................................................... 1763.10.2 Discussion ........................................................................................... 1773.10.3 Notification & Subscription .............................................................. 177

3.11 Additional Integrations ................................................................................... 1773.11.1 Exchange Infrastructure .................................................................... 1773.11.2 Replication und Synchronization ..................................................... 178

3.12 Supply and Maintenance ................................................................................ 1783.12.1 Configuration ..................................................................................... 1783.12.2 Java Development Infrastructure .................................................... 1783.12.3 Projects ............................................................................................... 1803.12.4 Testing and Monitoring .................................................................... 1833.12.5 Debugging .......................................................................................... 1833.12.6 Documentation and Help ................................................................. 1833.12.7 Internationalization ........................................................................... 1843.12.8 Upgrade and Versioning ................................................................... 184

3.13 Modeling Guidelines ....................................................................................... 1853.13.1 Data Types .......................................................................................... 1863.13.2 Entity Services .................................................................................... 1883.13.3 Application Services .......................................................................... 188

3.13.4 User Interface ..................................................................................... 1883.13.5 Naming and Other Conventions ..................................................... 189

4 Implementation Examples 191

4.1 SAP xApp Product Definition (SAP xPD) ..................................................... 1914.1.1 Introduction ....................................................................................... 1914.1.2 Business Case ..................................................................................... 1924.1.3 SAP xPD as a Solution ....................................................................... 2004.1.4 Summary ............................................................................................. 221


5/38


6/38

9Preface

Preface

In 2003, SAP introduced a revolutionary vision for the future of businessapplications: Enterprise Services Architecture (ESA). Many of the world's

top-performing enterprises adopted ESA in the first year after it wasannounced, reducing the cost of IT maintenance, and freeing upresources for innovation.

ESA is a radical shift in technology architecture. The last decade was dom-inated by the client/server-and-database approach to systems, an innova-tion also pioneered by SAP with the introduction of SAP R/3 in the early1990s. ESA is based on a service-oriented approach to applications. Byeliminating much of the impedance mismatch between systems andbusiness processes, ESA can yield much greater business agility whilesimultaneously achieving substantial reductions in total cost of ownership(TCO).

At the heart of ESA is a new platform. The platform of the 1990s was theclient operating system, server operating system, and relational database.Applications were each designed around their own information needs,often with complicated and expensive point-to-point integration acrossdatabases. This approach to application integration resulted in integrationcosts that consumed between 70 % and 90 % of the IT budget of typicalenterprises, according to leading analysts such as Gartner Group.

Client/server applications are designed with a dedicated client and server,each server used by a single application, and with integration performedby point-to-point data synchronization. ESA applications are designedwith shared servers (called components) used by many applications(called composites). The components expose a standard set of services,understandable to enterprise business processes. These standard services,such as create purchase requisition or order goods from inventory, are

called enterprise services.To realize this ESA vision, SAP introduced SAP NetWeaver in 2003. Abreakthrough platform based around the concept of integration, SAPNetWeaver has had the fastest ramp-up of any platform in history, havingbeen adopted by well over 1,500 of the world's leading enterprises by thetime this book went to press. By building integration capabilities intoeach component of the SAP NetWeaver platform, SAP can dramaticallyreduce TCO. The resources saved can be invested in innovation, used tocatch up on the application backlog, or returned to the business. Adopt-


7/38

Preface10

ing SAP NetWeaver was the first step on the road to ESA for many SAPcustomers.

One of the most unique capabilities of SAP NetWeaver is called Com-posite Application Framework (CAF), designed to reduce the cost of

developing and deploying composite applications. CAF is the basis onwhich SAP develops and delivers composite applications, including SAPxApps. SAP xApps are packaged-innovation solutions that delivernext-generation business practices with rapid implementation, very lowTCO, and competitive differentiation. SAP xApps are all designed usingESA, and are all powered by SAP NetWeaver.

This book captures SAP's experiences in developing both composite-application products and custom composite-application projects. The

authors designed, developed, and implemented these applications atcustomer sites. You'll learn everything you need to know about compos-ite applications and SAP xApps in this book, from the greatest experts inthe field.

We hope you will enjoy reading this book as much as we enjoyed creatingthis technology and writing this book. If you'd like to learn more aboutthe topics covered in this book, please visit SAP Developer Network athttp://sdn.sap.com/ you'll have access to the latest information, technol-ogies, and special offers to help you on your journey to composite appli-cations.

Dennis Moore

Senior Vice President, xApps

SAP Labs LLC


8/38

11Acknowledgements

Acknowledgements

Although only two people are named on the cover of this book as itsauthors, it would never have been possible for us to write it without sup-

port from and many discussions with our colleagues, partners, customers,and friends. This support went far above and beyond the call of duty,especially since the long distances between the people involved (PaloAlto in California, Sofia in Bulgaria, and Walldorf in Germany) and theresulting time-zone differences meant that telephone conversations hadto be held either very early in the morning or very late at night.

It would be impossible to name everybody who contributed to the suc-cess of this book. Therefore, we would like to mention just a few individ-uals and to acknowledge them in gratitude and respect. They are:

Rituparna Reddi , who, despite her already tight schedule, spent manylong nights in Walldorf describing user interfaces, helped us to under-stand the material, and thus regularly missed her last bus home.

Malte Kaufmann , who, without grumbling, provided detailed answers todozens of e-mails containing modeling questions, and, in several tele-phone conversations, supplied information and answers to questionsregarding functionality, technology, and application.

Jrg Schleiwies , who, without blinking, answered our toughest questionsabout integrating unstructured information in CAF, and explained all therelevant aspects in detail.

Frank Rakowitz , master of services.

Kalin Komitski , who answered and commented on our modeling ques-tions promptly, in detail, and with Bulgarian flair.

Tim Bussiek , Steffen Kbler , Thomas Anton , Jrgen Kremer and Werner

Aigner, who gave up some of their scarce free time to proofread this bookand give extensive, valuable feedback, and in particular, helped us to seethe CAF tree in the SAP NetWeaver forest.

Jrgen Hagedorn and Katharina Rock , who gave us the freedom to writethis book and were always ready with help and advice.

Gunther Piller and Andreas Henke , who always knew the answers to ourSAP xPD questions.


9/38

Acknowledgements12

Martin Botschek : a quick code example? Martin was always ready. Needa quick test environment? He just seemed to pull it out of a hat.

Stephan Bcker , who was always there for us with answers to our ques-tions about the SAP xApps Partner Program.

Yury Golovenchik, Alexander Efimchik, Alayxey Palayzhay and IharLakhadynau , who fell in love with the xFlights demo.

Natasha and Katrin , who kept us motivated, and always provided com-fort and encouraging words when writers block set in.

And of course, everyone else from the world of CAF and xApps, with-out whom we would have had nothing to write about.

Mario Herger and Jo Weilbach


10/38

115Entity Service

Remote Function Calls

RFCs represent the most frequently used method to communicate withan ABAP-based SAP system. RFCs are interfaces that enable a communi-cation with programs (so-called function modules) of an SAP system from

outside.Metadata importThe metadata of RFCs can be imported with the CAF and are then made

available to the entity and application services. During import, all meth-ods and their input and output parameters are notified to the CAF and aremade available for the CAF services.

tRFCABAP systems also use transactional RFCs . These run asynchronously. Thatmeans that although data which this RFC receives are written in a data-base table the transaction can only be completed by an explicit COMMIT

WORK.

Web Services

Web services have become widely accepted in recent times as the inter-face standard for communication on the World Wide Web across appli-cation and system boundaries. Independent of platform, program lan-guage, and technology, Web services enable systems and applications toexchange data and to start actions of any type. For the Web services,WSDL (Web Service Description Language) files are imported that can beretrieved from a directory or a UDDI 4 server.

External services (and entity and application services that we will describein further details later on) are the cornerstone of an Enterprise ServiceArchitecture and are used to flexibly create business applications.

3.5 Entity Service

3.5.1 Introduction

The Entity Service Modeler is a tool that can be used to model Entity Ser-vices, their attributes, methods, relationships with other Entity Services aswell as their general properties and behavior. The task of an Entity Serviceis to save and access application data. The data can be made accessible ina local storage in a backend such as an R/3 system or a Web service. Youwill find more information on the different persistences in Section 3.5.3.

4 You can find information on Universal Description, Discovery and Integration(UDDI) at http://www.uddi.org/ .


11/38

The SAP Composite Application Framework116

Creating andchanging

You can call the Entity Service Modeler in SAP NetWeaver Developer Stu-dio by creating a new or changing an existing Entity Service. Both actionsopen an editor that provides all properties that can be modeled, as wellas attributes and relationships of the Entity Service, in several tabs as wellas in the Properties window. In addition, this editor enables you to makechanges depending on your selections. The (technical) name of an EntityService can also be changed at a later stage and it will be registered on thename server during the check-in phase into the Design Time Repository(DTR, see also description of DTR in later chapters) provided the develop-ment takes place in the Java Development Infrastructure (JDI). 5

Comparison toABAP

In the ABAP world, the name server corresponds to the catalog of repos-itory objects (incl. Table TADIR) and the global TADIR (for cross-systemand cross-release developments in ABAP systems).

3.5.2 Modeling

Attributes The first general properties of a new Entity Service are the name, thepackage, and a short descriptive text. The Entity Service is automaticallyassigned a unique number (GUID) and creation and change dates as

Figure 3.8 Entity Service Modeler

5 If the name already exists, the check-in is canceled and an error message occurs.


12/38

117Entity Service

well as creation and change users are logged simultaneously. Thus theEntity Service is uniquely described.

The attributes and properties affect both the number of tables generatedand the scope of the coding which is generated as an Enterprise JavaBean

(EJB).

Several entities have already been identified for our xFlights scenario, andTable 3.1 shows a list of selected entities.

Characteristics ofattributes

As already mentioned the entity Person is described by last name, firstname, title, address, telephone numbers(s) and other attributes. Oncloser consideration it becomes apparent that these attributes have dif-ferent characteristics. The person has only one last name but can haveseveral first names. The person can also have several addresses and tele-phone numbers.

Addresses and telephone numbers can also be divided into several differ-

ent attributes. Thus the address consists of country, region, city, zip code,street, and street number. The telephone number can be broken downinto country code, area code and extension.

This requires different types of modeling for which it is important to knowwhich options are available to map this data. The CAF provides threeadditional types of attributes here in addition to the standard attributeswhich cannot be changed: simple, complex and entity-service attributes.

Entity Selected attributes of the entity

Person LastName, FirstName, Address

Flight CarrierID, FlightNumber

Airport Name, Altitude, Latitude

Plane PlaneType, MaxSeats, FuelUsage

Address Streetname, ZIPCode, City, Country

FlightSchedule DepartureTime, ArrivalTime, FlightNumber

Booking Person, Flight, Date

Business Partner lastName

Table 3.1 Selected Entities for xFlights


13/38


Standard attributes

When creating an Entity Service five attributes are automatically created.These attributes are: key, createdAt, createdBy, lastChangedAtand lastChangedBy. The attributes cannot be changed or deleted and

possess the cardinality 1..1 for key and 0..1 for the remaining four. EveryEntity Service thus contains a main table with at least five of theseattributes, regardless of whether it is locally or remotely persisted.

Meaning The meaning of these fields becomes clear when you consider the names.Key which is defined as GUID, is the unique primary key for this EntityService, createdAt and lastChangedAt provide the change history ofthe data records in date fields, and createdBy and lastChangedBy areused to store the change user as a 255-digit key of the UME.

The lastChangedAt attribute is also important because it is used for thedelta extraction of data into the BW. You will find a more precise descrip-tion of the BW extraction in Section 3.9.

Rules for attributeproperties

The appendix of this book contains a tabular overview of all rules whichitemize the property changes to all attribute types and describe thedependencies.

Simple Attributes

Simple attributes are generally simple data fields. In a table they wouldcorrespond to a column. In the Person example the attribute last namewould be a simple attribute.

Language andtime dependency

In the CAF world, a simple attribute can also be identified as language ortime dependent which entails the creation of an additional language ortime-dependency table. However, such an attribute can only be identi-

Figure 3.9 Simple Attributes and their Mapping in the Database

Person

LastName

FirstName

Telephone

Document

Add res s

Description

Simple attribute

Other attribute types

E n

t i t y

S e r v

i c e

Person-key


14/38

119Entity Service

fied as language dependent if it is of the basic type string and has thecardinality 0..1.

Only one language table is created per Entity Service. In the languagetable, an additional field is used for every language-dependent attribute.

This field is no longer available in the main table. In Figure 3.10 thisaspect is illustrated using the field Description.

Simple attributes can possess the cardinality 0..1 and 0..n or 1..1 and 1..nrespectively if they were entered as mandatory attributes at the sametime (the mandatory property is set to true). Regarding the database,the cardinality 0..n and 1..n means that an additional table is created witha primary key and an attribute. For this and all additional tables which arecreated for an Entity Service for the persistence, the name can bechanged in the Persistency tab. In the main table itself a foreign key isthen created which is a GUID for the CAF. In Figure 3.11 this is illustratedusing the field FirstName.

Figure 3.10 Language-Dependent Simple Attributes and their Mapping in the Data-base

Figure 3.11 Simple Attributes with Cardinality 0..n or 1..n and their Mapping in theDatabase

Simple attribute

Person

LastName

FirstName

Telephone

Document Add ress

Language

Person-Key

Langu

Description


E n t

i t y

S e r v

i c e

Person-key

Simple attribute

Person

LastName

FirstName-key

Telephone

Document

Add res s

Description

Firstname

Firstname-Key

Firstname


E n

t i t y

S e r v

i c e Person-key


15/38


Simple attributes can also be defined as keys by selecting the key prop-erty. This makes them automatically mandatory input fields and the car-dinality is set to 1..1. This cannot be changed subsequently. However, inthe database these attributes are not key fields but rather receive a

unique index. The standard attribute key is created as the only key fieldin the database itself.

Attributes which were defined as mandatory input fields or as keys areautomatically transferred as arguments into the CREATE method of theEntity Service.

Modeling tip As a rule of thumb, simple attributes are used if the attribute should notbe divided into additional sub-attributes and cannot exist independentlyfrom the referenced master data record. It should only be identified as

language dependent if the values entered have a commentary or descrip-tion field character. Reusable language-dependent texts such as colorshould be modeled as separate Entity Services.

Specific data types for attributes as are required for using currencies andunits will be described in Section 3.13.1.

This attribute type and all other types can be sorted in any way in theAttributes tab of the Entity Service Modeler.

Complex AttributesComplex attributes have several data fields. The data is stored in an addi-tional table in the database. In the Person example, the Telephoneattribute is a complex attribute which consists of the fields Countrycode, Region code, and Extension.

A complex attribute can also be created with the cardinality 0..n (oneperson has several telephone numbers). The sub-attributes themselvescan only be simple attributes and can have a cardinality of 0..1. A sub-

attribute cannot be a mandatory attribute (i.e. the Mandatory propertycannot be set to true). Complex attributes can neither be language-dependent nor defined as mandatory input fields.

Regarding the database, this means that an additional table with severalattributes is created. In the attribute of the main table, a foreign key isthen stored which is a GUID for the CAF.

Modeling tip As a rule of thumb, complex attributes are used if the attribute is to bedivided into additional sub-attributes and cannot exist independentlyfrom the referenced master data record. This means that, for instance, a


16/38


17/38


18/38


19/38


Category and CategoryValueSet together form a two-level hierarchy thatcan be used to categorize data records.

Modeling tip In contrast to the CustomEnumType (see also Section 3.7.5), which is dis-played as a dropdown field in the UI, a UI pattern must be used to cate-

gorize a data record. To do this, a more flexible two-level hierarchy is pro-vided.

CategoryService

As one of the last changes, the hierarchy functionality has been added tothe CAF support packages. This functionality enables you to create hier-archies with as many levels as you wish. In addition, several hierarchiescan also be created for the same values. The assignment to the objectinstances is carried out in the UI pattern Classification .

Document

By using the Document, any file types can be checked in to SAP Knowl-edge Management, where they can be requested from and edited. Typi-cally, these file types are Word documents, text files, PowerPoint files,PDFs, and so forth. If this CORE Entity Service is used as an attribute foranother Entity Service, a field of the data type rid is created in the maintable for the Entity Service. This data type then has a foreign key relation-

ship with the document.The Entity Service Document has the following attributes:

Key (String )

parentFolder ( String ; 0..1; key attribute)

parentFolder ( String ; 0..1; key attribute)

title ( String ; 0..1)

description ( String ; 0..1)

link (String ; 0..1)

contentLength ( long ; 0..1)

contentType ( String ; 0..1; contains the MIME type information)

relatedObjectRids ( String ; 0..n)

In the application the UI pattern Attachment is used as the user interface.


20/38

125Entity Service

Discussion

If Discussion is used as an attribute of an Entity Service discussions, userswill be able to discuss individual instances. These postings are stored inKM.

DiscussionRoom

In contrast to the Entity Service Discussion , DiscussionRoom enablesyou to restrict the access to a discussion. You can grant authorizations tothose who are permitted to take part in the discussion. This Entity Servicealso provides the functionality to send invitations to users to participatein a discussion.

Principal

Principals are used in the Entity Service DiscussionRoom and representthe individuals invited, i.e. the users authorized for this DiscussionRoom.

Topic

This service is used by the Entity Service Discussion. Each discussion canhave one or several topics.

Currency

This service is used internally in order to attach currencies to numericalattributes.

ExchangeRate

This service is used internally in order to execute conversions into othercurrencies on attributes with attached currencies.

UnitOfMeasurement

This service is used internally in order to attach units of measurement tonumeric attributes.

UnitConversionSimple

This service is used internally in order to be able to perform simple con-versions on attributes with units of measurement.


21/38


3.5.4 Persistence

Namingconventions

As already seen the modeling of an Entity Service has major effects on thepersistence. Deciding on a specific attribute type can be critical for addi-tional tables in the local database. The created tables follow a naming

convention, which has the prefix XAP_ and has a generated key as itsactual name. Due to length restrictions for databases supported by SAP,the table names cannot be longer than 18 characters. For this and otherreasons, a decision was made to assign the name of tables in this forminstead of generating any meaningful names. Other reasons were thepotential conflicts between attribute tables with the same names in dif-ferent Entity Services, conflicts when installing several xApps with theEntity Services bearing the same names, and also the ever-present temp-tation among application developers to directly access the tables. Insteadof this direct access, the corresponding APIs of the Entity Services shouldbe used.

The tables with the rather cryptic names of XAP_ can berenamed in the modeler by the developer. The names are registered onthe name server during check-in to the DTR. If the name already exists,the check-in procedure cancels with an error.

Other factors affect the table structure. In addition to the attribute type,

its data type and the key property, these factors are the language depen-dency, time dependency, the cardinality, and the decision concerning theuse of a local or a remote persistence. A precise explanation of these fac-tors follows.

Language Dependency

Language table If an attribute is referred to as language dependent, a language table iscreated that contains the foreign key of the data record, the language,and the corresponding text as fields. For each language-dependentattribute, an additional field is created in this language table. Dependingon the user log-on language, the text is selected and displayed in the cor-responding language during the application runtime.

An attribute which was identified as language dependent cannot have acardinality of 0..n or 1..n.

Time Dependency

Information as to when a value was valid can be mapped through thetime dependency of attributes. The last name or the address of a per-


22/38

127Entity Service

son can be time dependent. This property is stored in an additional tablethat contains the fields Key, Value, Valid from, and Valid until.Depending on the period of validity of the request, the correspondingvalue is selected from the time-dependency table and then displayed.

Cardinality

If there is a 0..n or 1..n relationship between the Entity Service and theattribute, additional tables will only be created in cases where this mod-eling cannot be mapped by the existing table structures. An attribute thatwas identified as mandatory (Mandatory property is set to true) canonly have cardinalities of 1..1 or 1..n.

Remote and Local Persistence

Subsequentchanges

In an Entity Service with local persistence, at least one table is always cre-ated. As already mentioned, the number of tables can vary according tothe type of modeling. If the Entity Service was already deployed once onthe J2EE server (which means that tables were created in the database)and if subsequent changes are then made to the attributes affecting thepersistence (i.e. the tables), the following cases can be differentiated:

Positive changes

Attributes are added. In a new deployment these attributes are gener-

ated as additions to the existing tables. The data remains in the tables.Negative changes

Attributes are removed. This is not permitted. During deployment atthe latest, the J2EE server sends error messages and the deploymentcancels.

Subsequent changes that have an impact on the language and timedependencies and the cardinality are only possible to a limited extent.The installation must previously be undeployed,or deleted on the J2EE

server.Remotepersistence

So far only the local persistence was taken into consideration. In additionto saving data in the local database on the J2EE server, the CAF also pro-vides the option to remotely read the data, to change it, save it, and todelete it. In this context remote means that data is stored in a back-endsystem, i.e. a downstream system. Back-end systems in CAF are all thosesystems whose data, is separated from the local CAF database, no matterhow it is stored.


23/38


24/38

129Entity Service

The CAF, or to be more precise SAP NetWeaver, for these reasons cur-rently provides no options for using generic functionality during a distrib-uted commit. This should not be a reason for ruling out the creation ofcomposite applications with SAP xApps, as in many cases either no dis-

tributed commit is required or it can be bypassed by taking other actions.

Access to the Local Persistence

JDOBut how do the operations access the local database? This occurs indi-rectly using Java Data Objects (JDO). JDO is an API developed by Sun inorder to be able to access data from any data sources through Java. JDOmakes access to the data sources transparent for the developers andrequires no SQL knowledge.

JDO is not used directly in the Entity Services but via the CAF-specificDataAccessService. During creation, two additional files with the end-ings .jdo and .map are created. The .jdo file contains the relationshipsbetween the Java class and the database table and is required when theCAF project is being built. During the build, the PersistenceCapableinterface is implemented in the Entity Services on the basis of the .jdo filein order to enable the JDO use. 6 The .map file can then read out theserelationships during runtime.

Access to the Remote PersistenceExternal ServicesIn order to receive data from a back-end system or to save it there, exter-

nal services are used and mapped to the operations. By mapping wemean the assignment of methods and parameters of the Entity Service tomethods and parameters of the external services.

Not all operations of an Entity Service must be mapped to the same one,to a different one, or to any external services. It is conceivable that theread method READ is mapped to an external service A, the FINDBY-

method XY to an external service B, and the write method CREATE to noexternal service at all, but that it stores the data locally. A practical exam-ple illustrates the mapping of the FINDBY methods to the BI-SDK 7 Webservice in order to search purchase order data and line items from SAPBusiness Intelligence. If this required data is found, it is once again readfrom the R/3 system and the changes are saved there. The reason for

6 If the class is decompiled, you can see this extension in the code. In the originalproject code the extension is not available at this point in time.

7 Business Intelligence Software Development Kit. This SDK enables you to accessdata from SAP NetWeaver Business Intelligence via Web services.


25/38


26/38


27/38


In addition, based on the settings in the Entity Service, operations are cre-ated such as

searchidxForBOInRelatedDoc

This operation belongs to the Entity Service Document and runs a searchfor all data records which contain a reference to a document. The opera-tion then returns a list of results.

During generation, in the complete coding authorization checks, loggingand tracing and other calls are automatically created as well.

3.5.5 Generation, Build and Deployment

While the services are being created and changed, the metadata also is

being created, links are being created, and coding and interfaces arebeing generated. For an executable application, Java dictionary objects(DDIC) such as tables, data elements, domains, views and metadata, andprogram and interface classes are required. During generation, these filesand configuration files are once again regenerated and during the finalbuild three archives are stored per CAF project. The archives contain theinformation on the DDIC objects, the metadata, and the compiled cod-ing.

Consistency check During the build itself, in addition to compilation, all references are alsochecked once again and the consistency of the archive is ensured. If theconsistency and links to references cannot be produced, the build cancelswith an error message.

Subsequent action If the build was successful, the archives can be deployed on the J2EEserver. By deploying, we mean the process of copying this archive tothe server and the execution of subsequent activities. A subsequentaction is, for instance, the creation of tables and database structures bycalling the information contained in the dictionary archive to execute cor-

responding SQL statements.

During the deployment, a check is run to see if the specified referencesare valid. If this is not the case, the deployment is usually canceled withan error message. However, if the deployment took place without error,the services are available to the application. The tables are created in thelocal database and are waiting to be populated.

The entire process of generation, build, and deployment is executed inone step and transparently for the user.


28/38

133Entity Service

Comparison toABAP

The comparable functionality in the ABAP Workbench would involvegenerating or activating objects.

Java Dictionary

Tables and their relationships to each other can now be created in thedatabase by using the information in the Java dictionary project.

Metadata

The metadata is stored in the metadata project. In the more than a dozensub-directories of the Meta Model, the definitions of interfaces,attributes, data objects, fields, mappings, operations, authorizations,properties and tables are stored in XML files. At least two XML files arecreated for each of the definitions referred to, even small applicationprojects can contain several hundred XML files.

Since these files are regenerated each time you use the CAF Designer toperform changes to the services, modifications executed on XML fileswith non-CAF tools are lost.

Apart from this, changes to the services, depending on the extent ofthese changes generally also affect more than half a dozen XML files.

Coding

TemplatesThe generation of the services is based on coding templates and metadatadefinitions. The coding templates for external, entity and application ser-vices and their interfaces can be found in the plug-in directory of the CAFDesigner under com.sap.caf.designer in the sub-directory templa-tes . More than two dozen templates are available there and can be usedaccording to the relevant definition.

The coding that is generated in such a way is then stored uncompiled inthe source directory of the EJB module project, the built archive that isready for deployment is stored together with the compiled Java classes inthe Deploy directory. Coding for Entity Services (and also application ser-vices) is generated in the form of sessions beans.

NoteAs the Java classes are regenerated each time you use the CAF Designerto perform changes to the services, modifications executed on Javaclasses with other tools are lost. We would therefore strongly advise youagainst making changes directly in the generated coding even if the temp-tation is great.


29/38


30/38

135Entity Service

3.5.7 Authorizations

The CAF employs the UME supplied with SAP Enterprise Portal to checkuser authorizations. In the Entity Service Modeler in the Permissions tab-strip the authorizations check generally takes place at the object level(Should an authorization check be carried out for this Entity Service?)and switched on or off at the instance level. The term instances refers tothe individual data records in this case.

ACLIf the authorization check was switched on at the instance level, anaccess-control list (ACL) is created for each instance. This list containsinformation on each data record for which authorizations are permittedfor which users or roles. The corresponding code sequence can then be

executed in the application service. There is an administration interface tomaintain the ACLs (see Figure 3.16).

In addition to maintaining ACLs, you can also create rules (business rules)and conditions there. The authorizations created can be imported andexported as well as propagated to referenced Entity Services.

Figure 3.15 ServiceBrowser


31/38


UME actions UME actions must be available so that the UME can work with the autho-rizations for operations of the application services. You can create these inthe CAF Designer using the Application Service Modeler.

The administration tool Principal Authorization Report is used in orderto be able to view the rule-based authorizations of a user for an EntityService for all instances (see Figure 3.17).

You can use this tool to display the authorizations but not to changethem. The authorization data can also be downloaded locally.

The reverse view of data, namely the display of authorizations for all rolesand users on one instance of an Entity Service occurs with the UI illus-trated in Figure 3.18.

Calling this UI, does not return any data at first because both the config-uration (and hence the Entity Service) and the instance are required. Theconfiguration takes place in the screen displayed in Figure 3.19.

The data cannot be changed here either. In order to transfer the instance,this UI canfor examplebe called from the ObjectSelector (of theObjectList ).

Figure 3.16 Authorization Maintenance for Users, User Groups and Roles


32/38


33/38


3.6 Application Services

3.6.1 Introduction

Business processlogic

The Entity Services described up to now primarily deal with generation ofcode for the relatively simple and redundant, butprovided they are tobe programmed manuallycoding-intensive tasks of data reading andwriting, which are prone to errors. Application services, by contrast, con-tain the intelligent part of the application, namely the business processlogic.

Application services are also the only way for entity or external services toget in contact with the UI in the CAF architecture, according to the ModelView Controller principle (MVC).

In the xFlights example, the most important application services wouldmainly be those for booking flights and all others which execute searchesfor data records in the Entity Services. Figure 3.20 provides an overview

of the application services in the sample scenario.

Figure 3.19 Authorization Report Configuration


34/38


35/38

Index290

Deploying 132Design Time Repository (DTR) 61, 179Development class 110Development component 179Discussion 125

DiscussionRoom 125Dispatch and follow up 235DocContent 143Document controller 238DTR 179Dynamic attribute 239

EEDI 278Electronic Data Interchange (EDI) 278Encapsulation 26Enqueue Server 169Enterprise Portals 280Enterprise Service Repository 265Enterprise Services 25, 278Enterprise Services Architecture (ESA)

27, 278Entity Relationship Diagram 100Entity Service 93, 100, 278ESA 278ESA platform 27

Excel 162, 216Excel export components UI 253Excel parsing API 251Exchange Infrastructure 177ExchangeRate 125Exploded BOM 242Extensible Markup Language (XML)

278External Service 94, 278Extraction templates 241

FFiltering mechanisms 230Fuzzy search 176

GGuided Procedures 87, 163, 213

action 87Guided Procedures Template 88phase 87process template 88process template design time 89

Guided Procedures Action Interface164

HHierarchical BOM 242

Hypertext Markup Language (HTML)278

Hypertext Transfer Protocol (HTTP)278

IIBM WebSphere 56IDE (Integrated Development Envi-

ronment) 60Implementation process 42Information integration 64Innovation costs 39Innovation risiks 39Integration Directory 63Integration Repository 63Integration Server 62Interactive forms 90, 164Interface 278Internationalization 184Internet standards 279iView 279

JJ2EE 279J2EE Engine 59JARM 183Java 2 Enterprise Edition (J2EE) 279Java Application Response Time Moni-

toring 183Java Community Process 59Java Database Connectivity 168

Java Development Infrastructure (JDI)58, 116, 178, 184Java Dictionary 61Java Management Extensions (JMX)

279Java Message Service (JMS) 279Java Server Pages 279JavaDoc 141JDBC 168JDI 116, 178JDO 129, 170JMS 279


36/38

291Index

JMX 279JSP 279

KKMIndex UI 123

LLightweight Directory Access Protocol

(LDAP) 279Locking mechanism 59

MMacro 154Mainframe 21Manufacturer Part Number (MPN) 224Market opportunities 18Market situation 17Microsoft .NET 56, 279MMR 106MMR cache 108Model View Controller (MVC) 91, 138Modeling 85Multi-Channel Access 279mySAP Business Suite 34, 279

NName server 116

OODBO 168OLAP BAPI 172, 173Online Analytical Processing (OLAP)

279Open Hub 173Open SQL 59Opportunity 239

Original Equipment Manufacturer 223

PPackage 110Packaged composite applications 35Pattern 85, 279People integration 74People Picker 253Perspective 97Placeholder 131Portal Content Directory (PCD) 77Portal runtime 77

Price extraction 235Principal 125Process Integration 61Procurement scenarios 235Product 191

Product definition process 192Product innovation process 191Project manager 236Purchase orders 241Purchasing info records 241

QQuery 153Quotation Worksheet (QWS) 234Quote package 246Quote team lead 236Quote team member 236

RRelease 279Remote Function Call (RFC) 279Report-report interface 173Repository 280Repository Manager 70, 176Retraction 172Reusable components 253

Revenue acquisition 223Reviewer 238RFC 279

transactional 115, 128RFQ 222Role 280

SSales employee 236SAP Application Server 57

SAP Business Intelligence 65, 280SAP Business Process Management63, 280

SAP BW 280SAP Collaboration 79SAP Composite Application

Framework 38, 42, 280SAP Content Management 69SAP Developer Network 172SAP Developer Studio 58, 60SAP Enterprise Portal 280


37/38

Index292

SAP Exchange Infrastructure 62, 63,95, 280

SAP J2EE Engine 60SAP Java Connector 60SAP Java Development Infrastructure

(JDI) 60SAP Java Test Tools 61SAP Knowledge Management 69, 280SAP Master Data Management (MDM)

281Central Master Data Management

73Consolidation 72Harmonization 73

SAP Mobile 74SAP Mobile Client 75SAP Mobile Infrastructure 75, 76, 281SAP Mobile Server 76SAP NetWeaver 35, 38, 55, 280SAP NetWeaver Portal 76SAP NetWeaver Solution Life Cycle

Management (SLCM) 80SAP Query 168SAP Web Application Server 281SAP xApp Cost and Quotation Mana-

gement 281

SAP xApp Emissions Management(SAP xEM) 49

SAP xApp Product Definition 281SAP xApp Resource and Portfolio

Management (SAP xRPM) 46expertise 48Portfolio 47Program 47resource 47

SAP xApps 33, 35, 36, 38, 40, 42, 281

SAP xApps partner program 41SAP xCQM 281SAP XI 280SAP xPD 191, 281SCA, Software Component Archive 111SDK 168, 172, 173SDM 108SDN 172Search 175

fuzzy search 176Secure Sockets Layer (SSL) 281Service modeler 94

Service Oriented Architecture (SOA)27

ServiceBrowser 134Sessions bean 133Simple Mail Transfer Protocol (SMTP)

282Simple Object Access Protocol (SOAP)

282Single Sign-on (SSO) 282Software Deployment Manager (SDM)

61, 108Software Development Kit 168Solution validation 45Sourcing bin 243Sourcing prep view 243Standard and moving average price

241Status 163Sub-attributes 131

TTable naming convention 126Taxonomy 70Team management 233Templates, coding 133Testing, service 134

Topic 125Transient attributes 83

UUDDI 115UI pattern 164, 279UML 102Unit 120, 188UnitConversion 143UnitConversionSimple 125

UnitOfMeasurement 125Universal Description, Discovery andIntegration (UDDI) 24, 282

VVersions 185Visual Administrator 108, 183

WWeb Dynpro 60, 282

foundation 164Web dynpro patterns 279


38/38

Documents

sappress xApps.pdf