Defining Multiple Component Views for an Integration Scenario
Use
You can define multiple component views for an integration scenario.
This is recommended if you want to have multiple combinations of product releases in an integration scenario, or want to permit multiple variants of an integration scenario.
The application components of the various component views are linked to each other by the uniqueness of the assigned roles. This means that you can trace the history of particular application components when using various different release combinations. You can also give the different component views different names.
Prerequisites
You have opened an integration scenario (see: Integration Scenario Editor).
Activities
Adding an Additional Component View to an Integration Scenario
You can add an additional component view to an integration scenario that is already based on a component view. For this purpose, you can copy the existing component view and use this copy for the new component view.
...
1. From the integration scenario editor toolbar, choose Component View ® Copy.
To define more than one component view for an integration scenario, you must have specified a role name for every application component in the existing component view.
2. The preview screen area on the left of the graphical editor displays all the existing component views. To display and edit a component view in the graphical editor, select a component view from this preview area.
3. You can enter a name for the component view in the Component View Name field.
Display all Component Views of the Integration Scenario
To display all existing component views in the preview area, from the integration scenario editor toolbar, choose View ® Show/Hide All Component Views. To select a component view and then display and edit it in the graphical editor, select a component view from this preview area.
Deleting a Component View
To delete a component view of an integration scenario, from the integration scenario editor toolbar, choose Component View ® Delete.
Wednesday, April 16, 2008
Defining Multiple Component Views for an Integration Scenario
Checking the Configurability of a Component View
Checking the Configurability of a Component View
Use
You can check whether the displayed component view is complete, so that it can be used in the integration scenario configurator as the basis for the generation of configuration objects.
Features
To check the configurability of a component view, from the integration scenario editor toolbar, choose Component View ® Check Configurability (This graphic is explained in the accompanying text).
The configurability check checks the following:
· Whether inbound and outbound interfaces and interface mappings are assigned in all connections
· Whether all abstract interfaces of the process signature are assigned connections for those application components that were assigned integration processes
Connections from or to an application component cannot be configured if the interface on the application component side is not part of the process interface.
Defining Multiple Component Views for an Integration Scenario
Defining Multiple Component Views for an Integration Scenario
Use
You can define multiple component views for an integration scenario.
This is recommended if you want to have multiple combinations of product releases in an integration scenario, or want to permit multiple variants of an integration scenario.
The application components of the various component views are linked to each other by the uniqueness of the assigned roles. This means that you can trace the history of particular application components when using various different release combinations. You can also give the different component views different names.
Prerequisites
You have opened an integration scenario (see: Integration Scenario Editor).
Activities
Adding an Additional Component View to an Integration Scenario
You can add an additional component view to an integration scenario that is already based on a component view. For this purpose, you can copy the existing component view and use this copy for the new component view.
...
1. From the integration scenario editor toolbar, choose Component View ® Copy.
To define more than one component view for an integration scenario, you must have specified a role name for every application component in the existing component view.
2. The preview screen area on the left of the graphical editor displays all the existing component views. To display and edit a component view in the graphical editor, select a component view from this preview area.
3. You can enter a name for the component view in the Component View Name field.
Display all Component Views of the Integration Scenario
To display all existing component views in the preview area, from the integration scenario editor toolbar, choose View ® Show/Hide All Component Views. To select a component view and then display and edit it in the graphical editor, select a component view from this preview area.
Deleting a Component View
To delete a component view of an integration scenario, from the integration scenario editor toolbar, choose Component View ® Delete.
Tuesday, April 15, 2008
SAP XI Tutorial
1. The first link is a brief, but very good overview of process integration and Exchange Infrastructure. It starts by explaining the old method of integration, and what XI can do to make complex integration environments more manageable and easier to develop.
XI Overview
2. The “ALE Quick Start Guide”. While this doesn’t necessarily directly relate to XI, I felt like it was important to list here as a prerequisite. This guide has a lot of great information, and a walk through of setting up an ALE scenario.
ALE Quick Start Guide
3. “A Beginners Guide to SAP XI Settings, Part I” is a paper written by members of the SDN which is very helpful in doing several things. First, it explains the multiple components of Exchange Infrastructure. Second, it explains some of the basic configurations for XI that need to be set in place in order to start developing interfaces. And it also begins to walk through an interface scenario.
A Beginners Guide to SAP XI Settings, Part I
4. “A Beginners Guide to SAP XI Settings, Part II” is the obvious follow up to the first half of this guide. It’s simply a continuation.
A Beginners Guide to SAP XI Settings, Part II
5. This next link is an excellent web page that provides a checklist for XI implementation methodology. Simply put, when developing an interface, this page is a great checklist to keep you on track. It’s worth reading over before reading some of the other links in this list of resources.
XI Implementation Methodology Worksheet
6. This is another document written by some SDN members. It expects the basics of XI to be understood, which at this point they should be, and explains an example File to IDoc scenario, including some good tips and techniques for mapping in XI.
IDoc Packing and Mapping Techniques
7. “SAP Exchange Infrastructure 3.0: Demo Examples” is an official SAP document that starts by explaining some configurations for XI (which can probably be skipped, but may be a good refresher) and finishes by going into great detail dissecting the example scenarios that are included with XI by default upon install. This is very helpful, because it walks through the examples in great detail.
SAP Exchange Infrastructure 3.0: Demo Examples"
8. This is a link to the SAP XI knowledge warehouse provided by SAP. It can be a bit frustrating for someone with no knowledge of XI, but at this point one should be able to comfortably navigate through the pages on this website and find the information they are looking for in particular. I would suggest reading all of the pages that are listed in the “overview -> basics” section, as well as the “overview -> examples -> demo examples” section to clear up any foggy areas.
SAP XI Knowledge Warehouse
Ref Src : http://mrharrison.blogspot.com/2006/05/learning-sap-xi.html
Printing and Exporting the Graphic Integration Scenario Editor
Printing and Exporting the Graphic Integration Scenario Editor
Use
The selected component view can be
· printed
· exported
Procedure
· To print a component view, from the integration scenario editor menu bar, choose Component View ® Print ( ).
· To export a component view as a JPEG file, from the integration scenario editor menu bar, choose Component View ® Export as JPEG ( ).
· To export a component view as a BPEL4WS file, from the integration scenario editor menu bar, choose Component View ® Export as BPEL4WS ( ).
You can use this function to import an integration scenario in ARIS for SAP NetWeaver, for example.
Designing Interfaces and Proxy Generation
Designing Interfaces and Proxy Generation
Purpose
Generally speaking, interfaces are where functions in a system can be executed. In the context of SAP Exchange Infrastructure, only the following interfaces are relevant:
· Interfaces designed for message exchange between application systems
· Interfaces used by a cross-component integration process to receive or send messages, or both
Starting with a cross-system integration process, you can then derive the corresponding interfaces required. SAP Exchange Infrastructure supports this process by using an integration scenario to describe the collaborative process. The integration scenario summarizes the interfaces required for this collaborative process.
You can use SAP interfaces that already exist in systems, non-SAP interfaces that are connected to SAP Exchange Infrastructure using adapters, or define new interfaces called message interfaces in the Integration Repository. Both worlds can also be interconnected in a collaborative process.
See also: Interface-Based Message Processing.
Integration
Interfaces are an essential component of SAP Exchange Infrastructure:
· You define the interfaces to be used in an integration scenario.
· Cross-component integration processes use interfaces to exchange messages.
· You define the XML transformations for messages that are to be exchanged between two interfaces in a mapping.
· You assign an interface in a sender system to one or more interfaces in a receiver system in logical routing.
· You generate proxies to implement your scenario based on message interfaces.
You save interface descriptions (message interfaces, BAPIs, RFCs, and IDocs) in the Integration Repository so that they can be referenced throughout SAP Exchange Infrastructure. However, adapters for external systems do not normally use interfaces; instead they access files or database tables in order to function, for example. For this reason, it is not necessary to import these interfaces into the Integration Repository. If the structure of the message is described using a WSDL, XSD, or DTD schema, you can import the schema as an external definition.
Features
Programming Models
You can use the following approaches when developing interfaces:
· Outside-In: You can develop new, platform-independent message interfaces by using the Integration Builder. Message interfaces are based on the WSDL standard Web Services Description Language), an XML schema for describing network services. Using this description, you can generate platform-specific proxies in Java or ABAP that you can then use to implement the actual message exchange.
· Inside-Out: You can connect interfaces from SAP and non-SAP systems to SAP Exchange Infrastructure by using adapters. The Integration Builder can import interface descriptions in XML format for BAPI, RFC, and IDoc interfaces from SAP systems Release 4.0 or higher.
By assigning the appropriate inbound and outbound interfaces, these two approaches can be integrated so that any combination of systems for exchanging messages using SAP Exchange Infrastructure is possible.
Tools in the Integration Builder
The Integration Builder supports both approaches by way of the following functions:
· Outside-In:
¡ Platform-independent definition of message interfaces. Data types for message interfaces are defined in XML schema. An XSD editor is available for this purpose.
¡ Generation of Java proxies directly from the Integration Builder.
To generate an ABAP proxy, use the object navigator (transaction SE80) in the SAP system in which you want to create the proxies. This is possible for SAP systems with SAP Web AS 6.40 or higher.
· Inside-Out:
¡ Import of BAPIs, RFCs, and IDocs from SAP systems Release 4.0 or higher.
¡ Use of imported BAPIs, RFCs, and IDocs in message interfaces to call them from ABAP and Java applications.
· Outside-In and Inside-Out:
¡ External definitions enable you to import WSDL, XSD, and DTD documents, from which you can extract message schema to use in other Integration Builder editors. External definitions support both the outside-in and inside-out approach: They exhibit a function that already exists in an application system (inside-out) and can also be used in message interfaces for proxy generation (outside-in). The same applies to RFC and IDoc messages. However, you cannot reference different object types from a message interface.
¡ Context objects simplify access to message fields. This improves the readability of conditions in integration processes and in logical routing.
For information about other general functions of the Integration Builder that are also useful for interfaces, see Integration Builder.
Thursday, April 10, 2008
NetWeaver SAPSetup Demo - Re-configuring packages VIDEO
NetWeaver SAPSetup Demo - Re-configuring packages VIDEO
SAP NetWeaver Portal create a transaction iView VIDEO
SAP NetWeaver Portal create a transaction iView VIDEO
Tuesday, April 8, 2008
Connectivity -- SAP NetWeaver Development
Connectivity -- SAP NetWeaver Development
● Remote Function Call (RFC)
RFC is the standard SAP interface to communicate with SAP backend systems and non-SAP systems. The RFC calls a function to be executed in a remote system.
● J2EE Connector Architecture (JCA)
The J2EE Connector Architecture (JCA) is a specification that defines the standard architecture for connecting the Java 2 Platform, Enterprise Edition (J2EE) platform to heterogeneous Enterprise Information Systems (EIS), which may include, for example, ERP and database systems. The mechanisms that the connector architecture defines are scalable and secure and enable integration of the EIS with application servers and enterprise applications.
Standard connectors, called resource adapters in the JCA specification, can be supplied by any given EIS. The connectors are software drivers used by an application to connect to an EIS. The connectors can be plugged into an application server, such as SAP Web AS Java, and provide connectivity between an EIS, the application server, and the enterprise application.
When an application server supports the connector architecture, it provides seamless connectivity to multiple EIS’s. Likewise, an EIS vendor provides one standard resource adapter and can plug into any application server that supports the connector architecture. JCA defines standard Java interfaces for simplifying the integration of enterprise applications with J2EE-based Java applications. The connector is a component library that can be used in Java by the developer.
● Java Message Service (JMS)
JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.
Since messaging is peer-to-peer, all users of JMS are referred to generically as clients. A JMS application is made up of a set of application defined messages and a set of clients that exchange them. Products that implement JMS do this by supplying a provider that implements the JMS interfaces.
Messages, as described here, are asynchronous requests, reports or events that are consumed by enterprise applications, not humans. They contain vital information needed to coordinate these systems. They contain precisely formatted data that describe specific business actions. Through the exchange of these messages, each application tracks the progress of the enterprise.
User Interaction -- SAP NetWeaver Development
User Interaction -- SAP NetWeaver Development
User interfaces:
● Web Dynpro for Java / Web Dynpro for ABAP
Web Dynpro is the recommended SAP NetWeaver programming model for user interfaces. The Web Dynpro model is based on the Model-View-Controller (MVC) programming model and allows a clear separation of business logic and display logic. The development environment provides powerful graphical tools to layout the UI; however, Java/ABAP skills are still required.
● Interactive Forms Based on Adobe Software
Developers can design, implement, and distribute—and users can access and manipulate—interactive forms from within or outside of SAP applications. End users access interactive PDF forms directly from their Web Dynpro application.
● HTML Business for Java (HTMLB)
HTMLB provides a number of Web controls for desktop applications, similar to Java Swing. The controls are based on servlets and JSP pages. The developer uses bean-like components or JSP tags. Unified rendering translates the components into HTML commands and guarantees unified design.
● Business Server Pages (BSP)
BSPs are a page-based Web programming model with server-side scripting in ABAP. BSPs give you complete freedom when designing UIs since any HTML and/or JavaScript can be sent to the client. With the HTMLB BSP extension, SAP also offers a library of predefined UI elements that simplify the creation of sophisticated BSP pages with a unified design.
● Java Server Pages (JSP)
JSPs are a page-based Web programming model with server-side scripting in Java.
● Dynpro
ABAP based UI development on SAP backend systems.
Process/Workflow:
● Guided Procedures (GP)
Guided Procedures provides tools and a framework for modeling and executing user-oriented workflows. It supports business specialists in implementing processes and guides casual users through the execution of these processes by helping them to understand their work context better and to contribute more effectively.
● WebFlow
This SAP technology guides employees in their tasks, automates process steps, and provides a logical framework that encourages – often imposes – efficient work practices. In addition, it supplies the performance metrics you need for monitoring and benchmarking internal processes. WebFlow is used to automate tasks and drive process flow across all applications and is particularly suitable for situations in which work processes have to be executed repeatedly, or situations in which the business process requires the involvement of a large number of agents in a specific sequence.
Web Services -- SAP NetWeaver Development
Web Services
Web services provide a standard for interoperating between different software applications running on a variety of platforms and/or frameworks. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. The interface is specified in the machine-processable Web Service Definition Service (WSDL) format. Other systems interact with the Web service as prescribed by its description using Simple Object Access Protocol (SOAP) messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
The UDDI (Universal Description, Discovery and Integration) has a central role for Web services. UDDI is a "meta service" for locating Web services by enabling robust queries against rich metadata.
Enterprise Service-Oriented Architecture -- SAP Netweaver Development
Enterprise Service-Oriented Architecture -- SAP Netweaver Development
Enterprise Services-Oriented Architecture (Enterprise SOA) is SAPs open architecture for adaptive business solutions. Enterprise SOA creates a gradual path to flexible, service-centric system landscapes and allows a non-disruptive transition of existing applications and architecture for more flexibility and value.
The fundamental premise of Enterprise SOA is the abstraction of business activities or events, modelled as enterprise services, from the actual functionality of enterprise applications. Aggregating Web services into business-level enterprise services provides more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications.
Model Driven Architecture (MDA) - SAP Netweaver Development
Model Driven Architecture (MDA) - NetWeaver Development
The Model Driven Architecture (MDA) is a new paradigm in server-side development. It insulates the business and application logic from technology evolution. This helps to generate program code quickly that is maintainable and independent of any application.
In contrast to the traditional development, the object model is built first, using the Unified Modeling Language (UML). The program code is generated by a tool that uses a pattern repository. The MDA paradigm has the following development steps:
...
1. Get business requirements
2. Design UML diagrams for the domain model. The UML diagram is technology independent and represents the core business services and components. Therefore at this stage the UML model is called Platform-Independent Model (PIM).
3. Create UML diagrams for a specific technology. The UML model is now called Platform-Specific Model (PSM).
4. Generate application code.
5. Add details, like business logic that could not be modeled in UML.
SAP Netweaver Architectural Background
SAP Netweaver Architectural Background
SAP NetWeaver is based on a dual-stack architecture based on ABAP and Java. While ABAP has been with SAP for years and provides a robust and scalable development and runtime environment for any type of business programming, Java is based on open standards and leverages SAP NetWeaver to the broad community of Java developers. In a service-oriented environment, however, the programming languages boundaries disappear, since components written in one language (for example, ABAP) can expose their capabilities as services that are used by components written in another language (for example, Java). The interoperability is achieved through Web service standards that have been implemented for both stacks. Likewise, SAP’s user interface strategy is built on top of the Web Dynpro programming model that is supported seamlessly both in the Java space and in the ABAP space.
The question of which environment you should use when depends on a couple of criteria that have to be weighed up carefully.
ABAP’s strength lies in its proven application server architecture. The language is based on a strong integration of OPEN SQL and manages large data sets known as internal tables. This allows use of ABAP in transaction-oriented environments with good performance. The development environment (ABAP Workbench) is tightly integrated in the application server. Since ABAP is essentially a server-based development infrastructure, working in large development teams is organized by the correction and transport system in a distributed development landscape. ABAP support a variety of data types that are optimized for business processes. Many important engines in SAP NetWeaver, such as the BI OLAP engine or the XI integration engine, are implemented in ABAP.
Java focuses more on the user-interface side although more and more applications make use of the entire Java stack from user interface to business logic and persistence. Many of the ABAP scalability features have been adapted for the Java stack, such as the proven scalability by means of a J2EE dispatcher and J2EE server nodes (that correspond to the ABAP dispatcher and work processes). The NetWeaver Development Infrastructure organizes distributed development in teams by means of central repository, build and transportation services similar in philosophy to ABAP’s change and transport system. However, there are subtle differences that have to be taken into account. Java development is carried out on the client side in the NetWeaver Developer Studio. A local J2EE engine makes it easy for Java developers to work offline and subsequently integrate their work into a central test system. Sources are checked out locally so that you only need to connect to the development infrastructure from time to time. SAP has implemented a lot of SAP NetWeaver components in Java such as the J2EE server itself, the Portal, the Developer Studio to name just a few.
ABAP and Java are code-based environments. Although they offer model-driven and highly graphical tools, such as the Web Dynpro View Designer and the Web Dynpro Data Modeler, you end up in editor and debugger sessions, since most of the developer’s work has to be done here. This excludes other types of roles, such as the business analyst, who typically has a lot of technical insight, but lacks coding skills in most cases. Here, SAP focuses on purely model-driven tools, such as the Visual Composer. The Visual Composer allows you to model the flow of your application or iView, helps to integrate various data sources, and makes deployment to the portal easy. It enables rapid prototyping.
Finally, it is important to note that SAP NetWeaver is in transition from an integration platform to a composition and business process platform.
Composite applications can be developed on top of SAP NetWeaver and are supported by the SAP Composite Application Framework (CAF) and Guided Procedures.
Both technologies accelerate composition on top of SAP NetWeaver, but are integrated in the Developer Studio and leverage existing technologies such as Web Dynpro and Adobe Forms integration.
Source:http://help.sap.com/saphelp_nw70/helpdata/en/42/c06f42ca95dc54e10000000a155106/content.htm
