Composite Development Architecture Guidelines14.1
Assumption 5: response time
E
E
Does your application require the called systems to respond within a certain (acceptable) time frame, or is it acceptable for your application to receive an answer minutes, hours, or even days later?
There are even more dependencies, but the message should be clear: loose coupling is not one-dimensional. For each of the aforementioned aspects of loose coupling, you have to make decisions. And they are not easy, because moving toward loose coupling has serious implications for the architecture of your application. So loose coupling comes at a price, especially in terms of complexity, and you have to decide whether you want to pay the price for it.
The benefit of loose coupling is flexibility and agility. If you are aiming for a loosely coupled approach, you will get unparalleled flexibility for adaptations to changing landscapes. Because you aren’t making any assumptions about the landscape your application is running against, you can easily adapt it as needed (provided your frameworks and tools support you like SAP NetWeaver Composition Environment does). This is especially important for partners and independent software vendors (ISVs) who can develop applications once and easily install and configure them at their customers’ side. The application itself stays untouched.
It isn’t just partners and ISVs who will benefit from this approach. It is useful within companies as well: Once you’ve established a successful new application, you will most likely want to reuse it within your company in other locations or regions. Very often, the IT landscape in the new locations differs from the one the application was originally designed for. If you take the loosely coupled approach right from the beginning, this undertaking will not frighten you. Another aspect you should consider is the probability of landscape changes during the lifetime of your new application. Due to mergers and acquisitions, or due to system
con-solidations, the landscape underneath your application is constantly changing. If you are not prepared for loose coupling, you’ll be forced to adapt your application again and again.
Concrete Implementation of Loose Coupling in Service Consumption
The concrete implementation of the loose coupling principle in a composite appli-cation can be performed as follows:
Enterprise services are used only via WS proxies in EJBs or SAP CAF external
E E
services.
There is an intermediate layer that abstracts from the underlying enterprise
E E
service so that only the used data is exposed to the composite application. The intermediate layer defines a service contract to the upper layers, and the imple-mentation of these interfaces is called a service contract impleimple-mentation layer.
The upper layers of a composite application (Web Dynpro, SAP NetWeaver
E E
Visual Composer, or SAP NetWeaver BPM) only use the service contracts.
Figure 14.8 shows the architecture of a concrete implementation of the loose coupling principle.
BPM Web Dynpro Visual
Composer
Service Contract
Enterprise Service Service Contract Implementation Layer
Loose Coupling Architecture Figure 14.8
With the service contract layer, it is possible to achieve decoupling from a concrete landscape, data-type structure, communication protocol, and so on. The service
BPM Tools — From Modeling to Execution 14
contract implementation layer can be implemented in different ways. First, the composite application design has to be clear if a complete decoupling has to be achieved. In that case SAP provides the following solutions:
SAP NetWeaver BPM
E
E
The service contract implementation layer implements an interface by using BPM modeling capabilities to allow execution of service calls asynchronously (see Asynchronous Write in Section 14.1.5). If an error happens during invoca-tion of the Enterprise Service, a full error handling including user steps can be implemented.
SAP NetWeaver Process Integration (PI)
E E
The implementation of the service contract implementation layer is not done via SAP NetWeaver CE; it is done via the process integration hub of SAP. The benefit is the same as the case of SAP NetWeaver CE; the only difference is that the capabilities of SAP NetWeaver Process Integration can be used (e.g., routing, ccBPM, etc.).
Java Message Service (JMS)
E
E
The service contract implementation layer contains a very small implementa-tion of the service contract, and only an event via JMS is raised that is processed on the Java server itself, so the message queue is used to decouple the function-ality. The benefit is that only Java EE technologies are used.
The above options decouple the execution of the enterprise service call from the basic composite application. If the asynchronous behavior is not a requirement, then the other technologies of SAP NetWeaver CE (SAP CAF, service composition, EJB) that transform the delivered data of the enterprise services to the composite can be used. This solution has the drawback that a complete decoupling of the UI parts of the composite application is not achieved; it goes in the direction of tight coupling with all of the disadvantages.
Structure of the Service Contract Layer in a Composite Application
The service contract and the service contract implementation layer have to be struc-tured in a way that real decoupling is achieved. Figure 14.9 shows the structure of a decoupled composite application.
SC
BPM Web Dynpro Visual
Composer
Service Contract
Enterprise Service
Service Contract Implementation Layer SC
Structure of a Decoupled Composite Application Figure 14.9
The entities of the composite application and the service contract definition are contained in one software component (SC), and the service contract implemen-tation is contained in another SC. The contract and the implemenimplemen-tation are in different SCs, because this allows switching of the implementations. These software components do not have any dependency, because they are loosely coupled and the communication between the composite application and the service contract implementation is only done via interfaces and configuration of the used services in the composite application.
Concrete Implementation of Tight Coupling in Terms of Service Consumption Loose coupling is not always the best architecture. If you don’t require flexibility, performance indicates that an intermediate layer is not allowed, or dependencies to the backend systems are not an issue, SAP NetWeaver CE allows all frameworks (Web Dynpro, SAP NetWeaver BPM, SAP NetWeaver Visual Composer, etc.) to call services directly. Figure 14.10 shows the architecture.
BPM Tools — From Modeling to Execution 14
BPM Web Dynpro Visual
Composer
Enterprise Service
Tight Coupling Figure 14.10
Example
The most commonly used implementation pattern in SAP NetWeaver CE is to implement an application service in SAP CAF that consumes one or many external services. The Java coding inside the application service is then responsible for mapping the data to the correct output data.
The intermediate SAP CAF application service is used if one of the following abstractions is required for the composite application:
Concrete landscape
E
E
The application services that are exposed by SAP CAF can be deployed with the composite application. If the landscape changes at the customer’s side, however, other application services can be implemented using the same signa-ture. Their implementation differs in such a way that the data is now retrieved from another system (or systems) within the customer landscape. Only a small configuration step is needed to activate the new application service for the composite.
Data type structure
E
E
The enterprise services provide a specific data type structure and require these data structures. If the application is not interested in all data, it is all right to implement an SAP CAF application service, define your own data types in SAP CAF, and only expose the data structures of CAF.
Communication protocol
E E
SAP CAF provides the functionality to call Web services and RFCs. If the appli-cation is loosely coupled in the sense that it should be able to run with Web services and get the data via similar RFCs later on, the recommended way is to implement an SAP CAF application service and implement the switch inside the
application service. Whether the data comes from an RFC or a Web service is transparent for the upper layers of the application.
Web Dynpro and SAP NetWeaver Visual Composer can follow either loose cou-pling or tight coucou-pling architecture styles depending on the specific requirements defined in the general considerations to use tight coupling or loose coupling.
Task Handling in a Process
A composite application usually contains process definitions and corresponding tasks. This section describes how to define the tasks.
As of Release 7, enhancement package 1 and enhancement package 2, the lifecycle of a task instance is bound to a surrounding process in SAP NetWeaver BPM, even though it is possible to define a task as a stand-alone artifact in its own DC.
Under very specific conditions, you can reduce the number of DCs. Imagine the following situation:
Multiple SAP NetWeaver BPM processes
E
E are modeled that contain a human
activity as their single artifact (ignoring start/end events).
The tasks that back the human activity all point to the same task UI and differ
E E
only in the occurrence of the process context.
The task description can be constructed by using/interpreting the process
con-E E
text.
In a situation like this, implement only a single, generic process, and create tasks and their work item description based on the process context, which needs to be fed accordingly by the start event message.
We therefore also recommend investigating whether existing processes, tasks, and task UIs can be refactored to make use of this approach.
As an example for a generic approach, you have a set of different processes run-ning in the backend (say process A and process B). For each of the processes, at a certain point a confirmation should be requested from responsible users. Instead of modeling the processes “confirmation for step x (process A)” and “confirma-tion for step x (process B),” model a single process, “generic confirma“confirma-tion.” Your start event message should carry all data that you require to make the necessary recipient determination and fill your fields in the confirmation UI. Add a human activity to the process. Implement your notification UI in Web Dynpro, and fill all task-specific information from the context. Connect your Web Dynpro UI as the
BPM Tools — From Modeling to Execution 14
task UI to the activity in your process. Pass all your task-specific details from the start message to the human activity/task (thus the Web Dynpro context) via data mapping.
Alternatively, if the confirmation task is still trivial and based on the same attri-butes of the different processes but requests different UIs, think of a gateway in the process to select the different task and thus the target UIs.
Extensibility
The extensibility configuration framework was introduced in SAP NetWeaver Com-position Environment 7.2, and the technology requires a specific structure. This section describes how the composite application has to be structured.
Extensibility is an important issue during the development of a composite applica-tion. Extensibility is normally understood as the ability of SAP NetWeaver CE to change an application behavior without design modification (only certain imple-mentations are replaced). The support of the composite application therefore stays, but new functionality can be plugged in.
There are many ways to design an application for extensibility purposes, but SAP NetWeaver CE provides a specific framework for extensibility. The extensibility configuration framework demonstrates an innovative conceptual approach, which allows different interface implementations of the application parts to be exchanged during the runtime of an application.
To do this, you first need to define extension points in your application. An extension point is a reference to a development object interface of a redirectable technology. The extension point allows exchanging or actually redirecting to dif-ferent interface implementations during the runtime of an application.
You can create extension points for the interfaces of the following development objects:
Enterprise JavaBeans (EJBs)
E E
SAP Composite Application Framework (CAF)
E E
Web Dynpro. In the (individual) Adobe Interactive Forms (AIF) use case, the
E E
extension point is not an interface, but a single form marked as extensible.
To create an extension point, there must be at least two development objects from one of the above types, because there needs to be a relation between them.
The extensibility configuration framework requires a specific structure of the appli-cation. The application has to be prepared to be extensible.
SAP CAF and EJBs have to follow the same principle. Even if the EJB is only a place holder, the redirect from an existing implementation in an EJB can only happen in an EJB container. Therefore, an EJB that has to be redirected has to be invoked from another EJB.
The consequence of this limitation is that an EJB that is consumed by a web application (Web Dynpro, servlet, etc.) has to be wrapped by another EJB, because invocation of the first EJB is performed by the web container, not the EJB con-tainer of the Java EE engine.
The extension components (components that replace the functionality of the com-posite application) have to be put in a customer product. The original product does not contain the extensions; the extensions are put in the customer product that has a dependency to the original product.
Separation of Functionality 14.1.4
SAP NetWeaver CE provides frameworks for different purposes. There are frame-works for business logic implementation, user interface modeling, and process modeling. The functionality of these frameworks sometimes overlaps, and you need to decide when to use which framework. The following explanations will provide some guidance.
UI Flow (SAP NetWeaver BPM and Web Dynpro)
The issue: The various steps of a user interface can be implemented in different ways. In particular, Web Dynpro and SAP NetWeaver BPM can be used to model the user interface steps. This section describes how to decide how to model the steps.
In general, both Web Dynpro and SAP NetWeaver BPM work well together for the realization of business processes or composites. How to wire them together or to use them exclusively depends on the concrete requirements of a business process.
As already described, business processes can come in a plethora of occurrences. In this chapter, we will focus just on human interaction, because this is where SAP NetWeaver BPM and Web Dynpro are complementary.
The two technical offerings are best described by the domains that they belong to.
SAP NetWeaver BPM allows you to model and execute workflows (generally it is a
A
A2A, 307
ABAP, 304, 370, 514, 529, 546 objects API, 516
technology, 551
ABAP-based business applications, 530 Abbreviations, 240
Accelerated transformation, 300 Account executive, 546, 547 Accurate communication, 71 ACR form, 191
Ad hoc collaboration, 620, 622 Adobe Document Services, 305 Adobe Forms, 170
Advanced planning, 237 Agile companies, 86 Agile methodology, 341
Agile techniques and practices, 399 Air compressors, 197
Aliases, 532, 535 Allied Electronics, 190
Annual business planning process, 172 Apple Computer‘s business model, 309 Application management tasks, 383 Application Migration Team, 151 Approver, 546
license management process, 243
methods and conventions for process design, 243
SAP Solution Manager integration standards, 243
Release Cycle Management, 243 training, 242
Artificial intelligence research, 632
Arvato AG, 65
Lead Logistics Services, 64, 65, 67 ASAP, 100, 119, 306
ASAP 7, 105
BPM/SOA-based business add-ons, 393 business add-on concept, 387, 400 business add-on for agile, 306, 400, 401, 403
business add-ons, 387, 389 core methodology, 359 cycle approach, 403
implementation content business add-ons, 554
implementation methodology, 339 implementation roadmap, 388
methodology, 202, 212, 301, 387, 399, 401
methodology and governance business add-ons, 393
Methodology for Implementation, 392 Roadmap, 344, 363, 379
Roadmap 7.0, 339
As-is process, 143, 151, 153, 165, 191, 199 Assortment planning, 395
B
B2B, 195, 307 applications, 631
Backend application, 201, 531 Background, 142, 150, 164, 190, 198 Balancing, 282
BISA (Business Intelligence Solution Accelerator) methodology, 339
Index
BPM, 21, 73, 96, 106, 233, 619 adoption, 123
based orchestration, 133
Center of Expertise (CoE), 246, 274 competency, 125 methods and tools, 199 principles and disciplines, 110 process flows, 203
(process lifecycle) principles, 111 project, 176, 427
Roadmap, 248
solution, 143, 154, 174, 191 suites (BPMS), 271
task force, 274 technologies, 297 tool, 171, 426 tooling, 565
Business Process Modeling Notation (BPMN), 176, 186, 194, 203, 226, 335, 620
artifact, 427
compliant process modeler, 138 diagram, 424
BPM payment process, 211
process transformation program, 214 Brazilian petrochemical industry, 206 BRFplus, 201, 203, 513, 514, 515, 524, 527, 528, 529, 543, 545
BRM, 145, 147, 158 decision tables, 211 BRMS, 498, 529 Build, 300
Business add-on to ASAP agile methodology, 399
Business analysts, 530
Business architecture, 105, 108, 110, 117, 236 Business blueprint, 115, 353
Business blueprint phase, 359, 362 Business case, 142, 145, 164, 190, 198 Business competencies, 46, 243
Business competency development vision/
roadmap, 50
Business configuration sets (BC sets), 403 Business governance, 251, 262
Business innovation and transformation, 46, 55
Business intelligence reports, 257 Business intelligence systems, 131 Business-IT alignment, 52, 74, 80, 108 Business logic implementation, 443 Business model, 28, 35, 252, 308, 327
analysis, 319 approach, 38 design, 40
improvement and optimization, 314 innovation, 31, 33
innovation and transformation, 26, 55 Business modeling, 49, 251, 316, 319 Business model management (BMM), 257, 337
Business networks, 58 BusinessObjects, 151
Business performance indicator (BPI), 271 Business practices, 622
Business process, 114, 151, 321, 619 expert, 249, 568, 570, 572 hierarchy, 322, 382
improvement, 367, 368, 369
management, 185, 198, 206, 235, 249, 250, 257, 266, 356, 634, 635
Business Process Management The SAP Roadmap, 57
Business process management (BPM), 21, 74, 105, 106, 117
principles, 311
Business process map, 348 Business process modeling, 632 Business process monitoring, 367 Business process operations support, 382 Business process optimization, 367 Business process requirements, 112
Index
Business process stabilization, 367 Business process stabilization and improvement, 369
Business process structure continuum, 620 Business process transformation, 253 Business Rule Framework plus, 513 Business rules, 141, 143, 147, 530, 531
maintenance, 499 management, 198
management system, 494, 498, 503, 511 system artifact(s), 506
Business scenario design, 348 Business services, 202
networks, 57
Business-to-IT linchpin, 71
Business transformation project, 138 Business value identification, 206
C
CAF BO, 463
Canonical data models, 241 CBM approach, 40 CCE AG, 172, 174 CE landscape, 420
Center of excellence (CoE), 385 CFO, 626 Coke One, 172, 178
template, 175 Combine, 76
Commoditization of products, 86 Communities, 604
Competency of the business model, 47 Competitive advantage, 318
Compliance solutions, 528
Component Business Model (CBM), 40
Components development, 40 Components of a business model, 36 Composite application, 433, 463, 470, 531 Composite designer, 417, 427
Composite in a Day workshop, 600 CompriseIT, 189, 191, 194 Consumer products, 162 Continuous improvement, 117 Co-opetition, 59
Core business, 266
competency innovation and transformation, 56
Core competitiveness, 53 Core differentiation, 53 Corporate management, 292 Corporate merger, 620
Corrective maintenance process, 231 Create a flow ruleset, 531
Create aliases, 531 Create a rule flow, 531 Create a rule script, 531 Create a ruleset, 531
Create business rules vocabulary, 531 Create decision tables, 531
Create definitions, 531 Create enumerations, 531 Create rules, 531
Critical core competencies (CCCs), 31 Critical success factor (CSF), 52, 89, 100, 271, 321
CTS, 516
Cultivating Communities of Practice, 249 Customer-centric business networks, 79 Customer-facing environment, 512 Customer-focused business competency innovation and transformation, 56 Customer satisfaction, 199 Customer service, 546
D
Danish Armed Forces, 253 Danish Defense, 251
Danish Defense value driver model, 262 Data Dictionary, 518
Data governance, 135
Decisioning, 512 Define value drivers, 243 Definitions, 532, 535 Deloitte, 138
Designers of business processes, 632 Development components (DC), 430 Development group, 307
Development infrastructure (NWDI), 189 Documentation, 549
Dot com era, 33 Due diligence stage, 623 Dunn & Bradstreet, 155
E
EA, 107, 247
governance and strategy frameworks, 341 metamodel, 112
Electrical engineering and electronics, 184 Electrocomponents plc, 190
Emergency maintenance, 199, 200 End-result-orientated solution paradigm, 59 End-to-end, 142, 163
operations, 206 processes, 131
process integration, 178 End user, 146, 167, 635 eNOVI, 210
Enterprise application integration layer, 195 Enterprise architects, 568, 572, 597 Enterprise-architectural methodologies, 107
Enterprise architecture, 73, 105, 106, 107, 117, 235, 236, 240
CoE, 248
framework, 110, 111, 573 practice, 246
Enterprise asset management, 546 Enterprise business model, 26
innovation and transformation, 26 Enterprise information management (EIM), 128
Enterprise IT architecture, 146 Enterprise JavaBeans (EJBs), 442 Enterprise portal, 147
Enterprise primary processes, 324 Enterprise resource planning, 70
Enterprise resource planning (ERP) solution, 266
Enterprise service bus, 586 Enterprise service orientation, 55
Enterprise services, 198, 415, 545, 546, 547, 549
Enterprise Services Repository, 175, 234, 302, 303, 304
Enterprise SOA Experience Workshop, 305 Enterprise SOA governance, 597
Enumerations, 532 EPC, 202
Ericsson, 141
ERP, 148, 175, 203, 209, 229 landscape, 223
paradigm, 75 system, 211, 228, 233 ES Repository, 171 ES Workplace, 548 ES Workplace systems, 549 Execution, 74
F
Facebook, 58 Fast translation, 71
Federal Enterprise Architecture Framework (FEAF), 108
Final preparation phase, 377 Final Price, 518
Financial processes, 163, 164
Index
Financial services, 161 Flat file, 370
Flexible IT solutions, 114 Flexible skeleton, 74
Flow-oriented modeling technique, 424 Flow ruleset, 529, 535
FOVISSSTE, 165, 167, 169, 170, 171 process, 164
Framework for organizing competencies, 49 Full structured processes, 621
Function-oriented enterprise, 56, 60
G
Gartner EA method, 247
Gartner (formerly the Meta Framework), 108 Generic acute-care, 236
GIS, 180 systems, 182 GISA GmbH, 179 Globalization, 141
Global master data management, 144, 150 Goal-oriented processes, 621
Go-live support phase, 378 Governance, 106
model for operations, 383 processes, 511
Governance, risk, and compliance (GRC) management, 253
Governmental-thinking organization, 255 Grid Asset Management Suite (GAMS), 186 Grid assets, 184
Grid operators, 184
H
Hewlett Packard, 66
Hewlett Packard Managed Printing Solutions, 64, 67
High tech, 163
Holistic approach, 337, 383
Holistic business model approach, 39 Holistic solution, 64
Hospira, 235
Hospira Information Technology, 237 HR, 229
system, 228, 233
Human capital management, 546
I
IBM, 146, 621
ICASIO pattern, 328, 332
Identification of value opportunities, 319 Identify performance parameters, 243 IDES, 222
ID mapping, 463 IDoc, 370
IDS Scheer, 199, 371
Industry model innovation, 26 Industry-specific IT solutions, 184 Information architecture, 105, 236 Information technology, 56, 108 Information technology systems, 108 Integrated change control, 342 Integrated infusion therapy, 236 Integrated payment process, 214 Intellectual capital (IC), 88
Internet-enabled networked markets, 59
Internet-enabled networked markets, 59