Introduction to SAP Netweaver 7.0 Usage Types(AS ABAP,AS Java,EPC,EP,BI,BI Java,DI,MI,PI)

Systems that are configured for a specific purpose, as indicated by one or more usage types.

Standalone engines that provide one specific (server) function in combination with one or more SAP NetWeaver systems.

Clients used by (many) people from their local front-end PC to access functions offered by systems of SAP NetWeaver or standalone engines in the system landscape.

USAGE TYPES

Application Server ABAP (AS ABAP)

AS ABAP is used to provide the ABAP foundation of SAP NetWeaver. AS ABAP can be combined optionally with other usage types in one system.

Application Server Java (AS Java)

AS Java is used to provide the Java foundation of SAP NetWeaver. AS Java can be combined optionally with other usage types in one system.

Capabilities of AS Java

• J2EE Engine - a J2EE 1.3-compliant application server for running enterprise applications.


• SAP Composite Application Framework Core (CAF Core) is a service-oriented architecture for building and deploying composite applications.


• Web Dynpro is the user interface technology for developing professional business applications for mobile as well as for desktop clients.


• Adobe document services is a set of runtime services that provide a range of form and document creation and manipulation functions.


• SAP Central Process Scheduling by Redwood adds powerful cross-component scheduling functionality to the integration capabilities of SAP NetWeaver. SAP Central Process Scheduling has to be installed separately after the AS Java installation.( http://sdn.sap.com/irj/sdn/nw-scheduling.)

EP Core (EPC)

EPC provides the basic portal capabilities for SAP NetWeaver. It brings SAP NetWeaver to the user in a uniform and consistent manner. It offers a single point of access through a Web front end to SAP and non-SAP information sources, enterprise applications, information repositories, databases and services across organizational and technical boundaries - all integrated into a single user experience. Usage type EPC is a prerequisite for using the portal add-on capabilities provided by usage type EP. EPC alone provides more flexibility when implementing a portal where the full enterprise portal capabilities are not needed.

EPC requires AS Java as a prerequisite in the same system. Optionally, it can be combined with other usage types in one system.

In addition to the Web front end capabilities, EPC contains the Universal Worklist and Guided Procedures (GP):

• Universal Worklist offers users unified and centralized access to their work and relevant information from within the portal. It collects tasks and notifications from multiple provider systems – Business Workflow, Collaboration Task, Alert Framework and KM Recent Notifications and displays them in a single list.


• Guided Procedures (GP) is a framework for modeling and managing processes that involve access to multiple back-end systems. GP enables runtime collaboration and execution of ad-hoc items. It also allows the invocation of various types of applications and services within a process, such as Web Dynpro and Business Server Pages (BSP) applications, and RFCs.

Enterprise Portal (EP)

EP requires EPC and AS Java as a prerequisite in the same system. Optionally, it can be combined with other usage types in one system.

The following portal add-on capabilities are tightly integrated into usage type EP:

• Knowledge Management (KM) enables portal users to distribute, access, and manage unstructured information within an organization in a heterogeneous repository landscape.


• Collaboration brings users, information, and applications together to ensure successful cooperation and interaction in the portal.


• Visual Composer is a powerful modeling tool that facilitates the creation of content on top of the SAP NetWeaver platform, enabling model-driven application development via a visual user interface rather than manually writing code.


• PDK for .NET offers a set of tools that enables Microsoft .NET developers to build portal content for SAP NetWeaver Portal.


• Adobe Flex server models applications that run in the Flash runtime, the Adobe Flex server is required to compile applications modeled in Visual Composer to Flash .swf files, for deployment to the portal.


• Application Sharing Server provides data streaming services that enable application sharing capabilities provided by SAP NetWeaver Collaboration. The server handles the flow of data between portal users collaborating through the real-time-collaboration-based application sharing feature.

Optionally, you can install the following add-ons on top of EP:

• Forums application provides a comprehensive range of discussion features which are particularly suitable for community scenarios. Forums typically focus on a specific purpose like support or human resources or they might offer customers a place to trade product tips and solutions.

• Web Page Composer add-on enables departments to create and publish Web sites for a company intranet or an external information portal.

Business Intelligence (BI)

BI provides the foundation for scenarios such as Enterprise Data Warehousing, Enterprise Reporting, Query, and Analysis, and Business Planning and Analytical Services. It includes the complete ABAP stack of the SAP NetWeaver BI data warehouse and BI platform units.

BI requires AS ABAP as a prerequisite in the same system. Optionally, it can be combined with other usage types in one system as well. Usually, scenarios running on usage type BI also require usage type BI Java - be aware that no matter if you run BI and BI Java in the same or in separate systems, you must keep them in sync concerning applied Support Package Stacks.

Business Intelligence Java Components (BI Java)

BI Java is used to provide the Java runtime for IT scenarios such as Enterprise Reporting, Query, and Analysis as well as Business Planning and Analytical Services. It enables variants such as Information Broadcasting and Ad-hoc Query & Analysis. It also enables Web Dynpro-based BI applications and third party data access via Universal Data Integration.

BI Java requires AS Java and EPC and EP in the same system. Optionally, it can be combined with other usage types in one system. Usually, scenarios running on usage type BI Java also require usage types BI and AS ABAP.

While installing BI Java, AS Java, EPC and EP get installed automatically. After configuring BI Java, you do not need to perform further steps in AS Java, EPC and EP.

Development Infrastructure (DI)

Development Infrastructure of SAP NetWeaver is used to provide the environment for all processes of Java-based development and Java-based software life-cycle management. DI requires AS Java as a prerequisite in the same system. Optionally, it can be combined with other usage types in one system.

For each IT scenario that uses SAP NetWeaver Development Infrastructure (NWDI), the following two Java development scenarios of NWDI define to what extent NWDI is used:

• Java Projects with Central Source File Storage: Development with central source code versioning only (that is, only DTR is used).


• Developing Components with the NWDI: All services of the Development Infrastructure and SAP's component model are used.

Mobile Infrastructure (MI)

Mobile Infrastructure is used to enable field personnel to participate in a business process in an "occasionally connected" mode. Occasionally connected means that a direct connection (using WLAN or GPRS) between mobile device and back end is only established at certain times - at synchronization points, when the Mobile Infrastructure Server (that is, the system with usage type MI) and Mobile Infrastructure Client exchange data in order to keep server and client updated.

Mobile Infrastructure uses Jakarta Tomcat 3.2.4.

MI requires AS ABAP and AS Java as prerequisites in the same system. Although technically possible, it is not recommended to combine MI with other usage types (besides AS ABAP and AS Java) in one system at the moment. Instead, it is recommended to install a dedicated MI system.

Process Integration (PI)

PI consists of core components that model, design, automate, and integrate processes in one or more application systems. For the integration of internal and cross-company processes, PI is used to incorporate all the functions of what was formerly known as Exchange Infrastructure (XI). In addition, PI contains core components for Business Process Management for application-embedded

and application-unbounded processes.

The service J2EE Adapter Engine (PI/XI) is also part of usage type PI. You use J2EE Adapter Engine (PI/XI) to connect to SAP systems (RFC adapter) and external systems.

We can use the J2EE Adapter Engine (PI/XI) that is part of your PI system as a central J2EE Adapter Engine (PI/XI).Optionally (for performance reasons), we can install a non-central J2EE Adapter Engine (PI/XI) separately as a system with AS Java and parts of the usage type PI on a separate host.

In addition, Partner Connectivity Kit (PCK) runs on AS Java with parts of the usage type PI.

PI requires AS ABAP and AS Java as prerequisites in the same system. Optionally, it can be combined with other usage types in one system.

It is recommended to have a dedicated PI system. For PI, it is a prerequisite that no other system in your system landscape has a higher release than the PI system. Although it should be technically possible to run an application system with a higher release than your PI system in your system landscape, this is not supported by SAP (apart from the exceptions listed in SAP Note 1043047).

Data Archiving - Requirements & Importing Archving Technology

The main purpose of data archiving is to remove from the database application data that is no longer needed in day-to-day business, with the aim of using resources more efficiently. The following requirements must be taken into account when archiving data:

• Legal requirements: Some kinds of data must be archived so that they can be analyzed at any time in the future, for example data required by the tax authorities. These requirements are subject to the laws of the relevant country. SAP has developed the Data Retention Tool (DART) to enable the US Internal Revenue Service to analyze archived data. The tool includes functions for creating transparent files from archived data and to display this data.

• Technical requirements: From a technical point of view, the question is whether data can still be read long after it has been archived, independent of the hardware used at the time of archiving and the software release status. To guarantee this, SAP Data Archiving stores, together with the actual application data, additional information about the hardware that was used to write the data to the archive and what type of data structure was applied.

• Business requirements: From the business point of view, only those data objects that are no longer required in day-to-day operations may be removed from the database. Therefore, a logic check must be performed to ensure that only data objects belonging to completed business processes can be archived. The high level of integration between R/3 System applications means that the data objects are closely linked. Consequently, it is essential, during archiving, to check whether the removal of a specific data object from the database requires other objects to be archived at the same time.

Important Archiving Terminology

Reorganization

This term has a double meaning in the SAP context. Firstly, it refers to the physical deletion of application data from the database. Secondly, - the true meaning - refers to the reorganization of the database.

In the database, individual table lines containing datasets are stored in database blocks. Deleting, changing and creating datasets creates gaps in the blocks. These gaps can no longer be used. Fragmentation of the database can, in some circumstances, increase the time needed by the system to search for table contents.

Removing the effects of this fragmentation by closing the gaps and thereby enabling more efficient use of the available memory space is what is meant by the term (database) reorganization. This process entails the physical relocation of data from a logical database segment to a contextually-related area in the memory.

Optical archiving

Optical archiving refers generally to the electronic storage and management of documents in storage systems beyond the R/3 System. In most cases, data is stored in optical media such as CDs or WORMs;hence the designation "optical archiving". The term is, however, confusing, and it would be preferable to refer to "imaging" or "electronic data storage" since the term "optical archiving" only describes the physical storage. In principle, all media - and not just optical storage media - can be used that are supported by the storage system that is connected to the SAP System.

Documents that can be stored in this way include

Scanned original documents such as suppliers' invoices

Outgoing documents, such as invoices that are created electronically in R/3 and then forwarded

Print lists created in R/3

In these cases, the documents created are not stored in the R/3 database, but are transferred to document storage systems. The SAP System only maintains links to the externally stored document, thereby enabling access. Documents that are stored (not archived) in this way can be displayed in R/3, but cannot be reloaded into the database. This is due to the different formats in which documents and applications are saved. Whilst application data is stored in the database in a structured format (CI, coded information), scanned documents are stored in NCI format (non-coded information), which cannot be interpreted by the applications.

SAP ArchiveLink

SAP ArchiveLink is an interface that is integrated into the SAP Basis component. It controls communication with storage systems. This standard interface enables access to documents created in SAP applications and stored in a storage system. The storage system must be correctly configured and connected to the R/3 System.

Backup and Restore

Backup refers to the (saved) copy of the database contents that serves as a precaution against data loss. This enables the reinstatement of the database as it was before the system failure. Restore refers to the rewriting of the contents of the backup copy in an emergency.

The following defines more precisely the term Data Archiving:

"Data Archiving is the consistent removal of data objects from the database. This involves writing all table entries that define a data object in archive files outside the database. Consistency of business data is ensured by the SAP archiving programs, which remove all the relevant table entries."

Creating Background Jobs - Job Steps

 

¨ ABAP programs. With this option, you can specify the execution of ABAP reports as steps of a background job. Module pools or functions groups are not allowed for definition as steps.

 

¨ External commands. These are predefined commands that should have been previously defined by the system administrator. Normal users with the required authorization can schedule these job steps.

Since this is a way of executing programs or commands outside R/3, for security reasons users have to specify the operating system type and cannot change the predefined arguments.

 

¨ External programs. These programs are unrestricted operating system programs or shell scripts that require batch administrator privileges. There is no need to define these commands using transaction SM69. The requirement is that the computer must be reached from within the SAP server and have either remote shell support, a running SAP gateway, or a SAP instance that is on the reach of a SAP gateway.

 

 

Scheduling ABAP Programs as Job Steps

 

When scheduling ABAP reports as job steps, there are several type parameters which can be specified. The most important one is usually the selection criteria for the execution of the report as it would be normally specified when launching the report online. A group of selection criteria is saved in variants.

When an ABAP program is specified as part of a background job, if it needs selection criteria, the variant must have been previously created, otherwise you will not be able to save the ABAP step.

 

To define an ABAP program as a job step, from the initial job definition screen, press the Step button, and then click on the ABAP Program button on the Create step screen. Then proceed as follows:

¨ The User input field will be filled automatically with your own user name. But you can select another user name which will be used by the system to check the

    authorizations for the running job. You can only enter another user name if your own user is authorized to do so.

¨ Enter the name of the ABAP program in the Name input field.

¨If the ABAP program has selection fields, you must enter a variant in the Variant input field. If you don't know the name of the variant, click on the Variant list 

   button and select one. If you don't have any variant defined, you have to first define at least one variant, otherwise the system will not let you schedule the job. You

   can leave this field blank only in the case that the program does not require variants.

¨ Finally, in the Language input field, you can select a different language than the default, which is the one used when logging in to the system. Since SAP R/3 is a

    multilanguage system, there might be some language−dependent texts in the program which will be affected by the value of the language field.

 

 In the definition of steps with ABAP programs, you can also specify print parameters to instruct the system on where and how to print the job output.

When finished entering the needed information in the input fields, you can check your definition by clicking on the Check button. The system will display a message in the status bar if it finds any errors in the job definition. If there are no errors, click the Save icon to save your step.

 

 

Scheduling External Commands

 

Both external commands and external programs are executed by means of the sapxpg program. This program is called either by a remote shell (rsh, remsh, and others) or by the SAP gateway (the usual way under Windows NT systems).

External commands to be scheduled must have been previously defined by the system administrator (transaction code SM69).

 

¨To define these commands as job steps, first click on the External command push button on the Create step dialog box.

¨On the Name input field, click on the possible entries arrow to select one of the available external commands.

¨Only the commands available for the target operating system can be successfully executed.

¨The Parameters input field is used for specifying additional flags or parameters for the command.

¨Select Operating system from the available options, and the target host where the command will be executed.

¨Finally, verify the definition by clicking on the Check icon. If no errors are found, proceed by saving the step definition.

 

 

Scheduling External Programs

 

You can schedule external programs as job steps. These external programs can be of any type as long as they can be reached from the R/3 server and the host where the program resides can execute the program itself. It can be any compiled or executable program, shell script, and so forth.

 

The step definition for external programs allows you to include any parameters the program needs in a complete transparent way. The error messages generated by external programs are included in the log file for the background job.

 

To enter an external program as part of a job, when on the Create step screen, click on the external program.

The system will change the colors for the relevant input fields while graying out the field for the ABAP programs. Notice how the command buttons in the lower part of the screen change as well, depending on the type of program.

Enter the following information for the external program:

¨ Name. Enter the name and path of the external program. You should enter the path to ensure that the program can be found in the target system except if the

   program is in the search path of the SAP user with which the R/3 gateway was started (normally the <sid>adm user). For example: enter /home/dd1adm/copy.sh,

   instead of entering just copy.sh.

¨ Parameter. Enter here any parameters, flags, or options that the external program might need. For example, if the program /usr/bin/ps needs the option −eaf, enter

   this value in the parameter field.

¨ Target host. You have to enter here the hostname of the server where the external program is to be executed. This host must be reachable from the R/3 server.

 

Defining Background Jobs

 

Starting background jobs is a two−step process: you first define the job and then you have to release it.

 

When users define a job and save it, they are actually scheduling the report, that is, specifying the job components, the steps, the start time, and the print parameters. So, to schedule a job is the same thing as to define it. More precisely a scheduled job is a job definition which has been saved.

When users schedule programs for background processing, they are instructing the system to execute an ABAP report or an external program in the background.

 

Scheduled background jobs, however, are not actually executed until they are released. When jobs are released, they are sent for execution to the background processing system at the specified start time.

Jobs are released automatically if the user is authorized to release jobs, and they automatically start the execution in the background system if the user has chosen the start immediately option.

Both the scheduling and the releasing of jobs require authorizations. Standard SAP users have authorization which allow them to schedule jobs; however, releasing jobs is a task normally assigned to the system administration and requires another authorization. Protecting the releasing of jobs with authorization enables system administrators to better monitor and maintain the background system and allows the available resources to be better distributed. The drawback is that scheduling jobs is such a common task that it can surpass the administrator's ability to maintain the whole system. Therefore, reserve some time for studying which users should be allowed to release their own jobs.

 

When users do not have release authorization, the start time or frequency they specify does not have any affect at all, except for informing the administrator in charge of releasing them of their preference for executing the job. Administrators or users with authorization for releasing jobs can change the start time

specifications and the interval.

 

When scheduling jobs, users can specify several steps, each having a different report or program. Each step has its own attributes, such as authorized users or print parameters. The same job can contain steps with ABAP reports and steps with external programs or commands.

 

When defining jobs, users also have the option of scheduling a program as a separate job or modifying an existing job which has not yet been processed and adding it to the list of job steps.

Users, and especially administrators, should avoid having too many released jobs during normal, operative working hours, since the system processes the background jobs during online operation where there are available background work processes. Remember that a background job will perform the same tasks as if the functions were performed online. So, if a background job does lock a table or updates the database, it will have an immediate result and can affect the work of online users.