SAP NetWeaver 7.3 AS Java Introduction

1. SAP NetWeaver 7.3 AS Java Introduction By Phani Kumar DS

2. NetWeaver 7.3 • The new version is set to become available at the start of 2011 and provides a whole range of revised functions. For example, release 7.3 supports Java EE 5 as well as Enterprise Service Bus (ESB) for Java. The Java Message Service (JMS) is also new as a publish-and-subscribe function. Furthermore, SAP NetWeaver 7.3 supports WS Policy 1.2, SOAP 1.2, WS Trust 1.3, Java SE 6, JSR 168/286, WSRP 1.0, and SAML 1.0/2.0.

3. Architecture The AS Java system consists of three logical layers: • Java Enterprise Runtime - comprises low-level subsystems that provide functions such as class loading, cluster communication, persistent configuration data management, and so on. • AS Java System Components - consists of facades, interfaces, libraries and services components that provide various runtime functions and programming APIs. • Applications - refers to the applications that are deployed and run on AS Java.

4. Architecture

5. Components The following types of components exist: • ●      Facades – they simplify the relationships between SAP NetWeaver layers and client applications. Facades are the only official way for clients to access the AS Java API. They help to define what is an ‘external (publicly available) API’ and what is an ‘internal API’. Everything that is part of a facade is public and the client code must be built against it. Everything that is not part of a facade is not official and the client code should not rely on it. Clients in this context can be components from other layers of the product and customer applications. If a client needs a reference to the public API of a certain component (service, interface, or a library), it must reference the facade which contains the API of the component. • ●      Interfaces – they define how different components of the system work together. At runtime, they provide the system with their name and classes (no objects). They are used by services components that provide their implementation. • ●      Libraries – they provide name, classes and objects to the system. These objects are created by the system when it loads the library, or when an object is first requested. Libraries are not active components – they have no definite life cycle, do not allocate resources themselves and do not keep any kind of configuration information in the system. Other library components or services components usually access them using static methods. • ●      Services – they provide the system with their name, classes, and runtime objects. The runtime objects are registered in the system once the components classes have been loaded. Service components can access and utilize functions of the runtime through the Framework API. Services are active components with a definite life cycle. They can allocate resources at their startup time and are responsible for releasing them at shutdown time.

6. Features • The AS Java system architecture is based on the following general rule: components from a higher level can use components from a lower level only through a set of defined APIs - facades; whereas components from a lower level are not aware of the APIs of the components from a higher level and therefore cannot use them. • This rule is reflected by the order of starting the system modules: the runtime is started first, then the services (the libraries are loaded, the interfaces resolved at this phase), and the applications are started last. The system is considered as started when all runtime managers and core services components are started properly. • The AS Java system components use the Framework APIs to connect to the Java enterprise runtime. Applications use the AS Java system components using the APIs that are defined by Java EE 5 specification (and supporting specifications) and SAP-proprietary APIs.

7. Standard SAP Java System Based on SAP NetWeaver 7.2 and Higher

8. Standard SAP Dual-Stack (ABAP+Java) System Based on SAP NetWeaver 7.2 and Higher

9. Additional Application Server Instance (Dialog Instance)

10. Dual-stack (ABAP+Java) system

11. AS Java Cluster Architecture Central services instance • The central services instance consists of a Message Service and Enqueue Service. They are responsible for lock administration, message exchange and load balancing within the Java cluster. One or more Java instances • A Java instance consists of an Internet Communication Manager (ICM) and one or several server processes. The ICM handles requests coming from clients and dispatches them to the available server processes, which actually process the requests. Database • The database stores system and application data. There is one central database. It is also possible to have several application databases.

12. Minimum AS Java Cluster Installation

13. Large AS Java Cluster Installation

14. Load Balancing in AS Java Load Balancing Among Java Instances • There is a central load balancer, which lies between the Internet and your system and serves as the entry point for all user requests. For this purpose, you can use the SAP Web dispatcher. It is a standalone program that distributes incoming Web requests (HTTP, HTTPS) evenly among the Java instances within your AS Java cluster. • If the request is coming from an external client over a remote protocol (RMI-P4), it either goes to the Message Server, which dispatches it to an available Java instance, or it is directly dispatched to an ICM that redirects the request to one of the server processes in the Java instance. • Load Balancing Within the Java Instance • After client requests are dispatched to the Java instances, they are then handled by the ICM. The ICM chooses the most appropriate server process within the Java instance and dispatches the request to it.

15. The Startup Framework for AS Java   The Startup Framework provides the following services: • It serves as a single point of administration (starting, restarting, stopping, and monitoring) for the AS Java processes. • In case of a process failure, it restarts the corresponding process. • It displays the trace files, the system environment, and the SAP system environment. • It provides options for thread dump monitoring. • This option is critical for the analysis of problem situations (for example, the AS Java is hanging, 100% CPU load). • It provides options for viewing the Java VM output (useful in case of a Java server crash).

16. Architecture of the Java Startup Framework

17. JSTART The Java Startup Framework is implemented in the JSTART program. The JSTART program has two roles: • When running as the Java instance controller, JSTART starts, stops, and monitors the processes of a Java instance (the ICM process and several Java server processes). In this role, JSTART provides a local port for command communication and implements the SAP signal handling to stop the instance. • In the role of a server process, JSTART connects to the Java instance controller before loading the Java VM into its address space. It then starts the AS Java code and represents the Java server process. The program can receive commands from the Java instance controller and reports the status of the Java server to the instance controller. A Java server process stops immediately when it detects that the Java instance controller has terminated unexpectedly.

18. Integration • In an ABAP+Java instance, the ABAP dispatcher calls the JSTART program. • In a pure AS Java installation, the following distinction applies: • Under Windows, the SAP Start Service calls JSTART to start an AS Java instance. • Under UNIX and OS/400 platforms, the SAP Start Service uses the startsap and stopsap scripts to call the JSTART program.

19. Startup of the Java Instance

20. Startup of the Java Instance • JSTART is started (in Windows by the SAP Start Service; on UNIX platforms by the startsap script). It takes the role of the Java instance controller. • The Java instance controller analyzes its configuration (from the instance profile) and examines the details of the Java SDK defined there. • The Java instance controller initializes SAP signal handling to be able to receive signals and opens the control port. • The Java instance controller reads the instance description (from the list of files specified by the jstart/startupNodeFiles and jstart/instanceNodeFiles profile parameters) for the first time, searching for nodes with a runLevel=1 property. The OFFLINE DEPLOYMENT node in the startup.properties file matches this criterion. • The Java instance controller starts another JSTART process with the parameters from the OFFLINE DEPLOYMENT node and waits for the child process to terminate. • The child process acts as a Java process. It loads the Java Virtual Machine (JVM) into its own process, initializes the JVM and starts the OFFLINE DEPLOYMENT program, which performs the deployment steps in the Java database.

21. Startup of the Java Instance • The Java instance controller reads the instance description again, searching for nodes with a runLevel=2 property. The BOOTSTRAP node in the startup.properties file meets this condition. • The Java instance controller starts another JSTART process with the parameters from the BOOTSTRAP node and waits for the child process to terminate. • The child process loads and initializes the JVM and starts the BOOTSTRAP program. BOOTSTRAP synchronizes the binary data in the Java database with the local file system, reads the Java instance description from the Java database and updates the instance.properties file. • The Java instance controller reads the instance description from the startup.properties and instance.properties files once more, this time focusing on nodes with a runLevel=3 property or without a runLevel property at all. These nodes form the productive instance. • The Java instance controller starts the processes for infrastructure nodes, such as ICM or DEBUGPROXY. • When all infrastructure processes are started, the Java instance controller starts the processes for the server nodes. • The JSTART child processes act as Java processes and execute a similar sequence as described before. They become the Java server processes.

22. Shutdown of the Java Instance

23. Shutdown of the Java Instance • An instance is stopped as follows: • A process (for example, the ABAP dispatcher, a start script or SAP Start Service) sends a SIGINT signal or an appropriate command to the Java instance controller. • The Java instance controller updates the instance state and sends STOP commands to the server processes. • When the server processes are finished, the Java instance controller sends STOP commands to the infrastructure processes. • Once all child processes have exited, the Java instance controller terminates.

24. Administration of the Java Startup Framework • Administration and monitoring with the SAP Management Console • Administration and monitoring with the command line program jsmon • Monitoring and interpreting the trace and log files created by the framework, analyzing the error messages in them, incrementing/decrementing the trace levels, creating stack traces

25. Using the Command Line Program jsmon Prerequisites • The AS Java instance is running. • You are logged on at operating system level to the computer where the AS Java instance is running. In the following <profile> refers to the name of the profile file with which the Java instance controller was started. Procedure • Call jsmon pf=<path to profile> from the command line. • The JStart Monitor Program is started. Some options are displayed. • Call —help. • A detailed list of possible commands and corresponding operations is displayed. • Refer to that list when performing operations.

26. Developer Trace and Log Files • The developer trace and log files are located in the /usr/sap/SID/inst_name/work directory dev_jstart • This is the trace file of the Java instance controller. dev_<component name> • The trace file of the corresponding JSTART server process (the <component name> can be deployment, bootstrap, server<n>, or icm). For example, the trace file for the bootstrap process is dev_bootstrap. std_<component name>.out • The standard and error output file of the corresponding JSTART server process (the <component name> can be deployment, bootstrap, server<n>, or icm). jvm_<component name>.out • The standard and error output file of the JVM running the corresponding JSTART server process (the <component name> can be deployment, bootstrap, or server<n>).

27. Configuration of the Java Startup Framework Command line arguments for the Java Instance Controller SAP Instance Profile • The SAP instance profile that contains all properties related to the AS Java instance. This file is normally created by SAPinst and contains the SAP instance properties, such as SAPSYSTEM (system number) or SAPSYSTEMNAME (system ID), and so on. • Program argument: pf=<filename> • Internal default value: this parameter is mandatory; there is no default value Bootstrap Mode • This option allows you to skip the offline deployment and bootstrap phases when the Java instance is started. • Program argument: -bootstrap=[yes/no] • SAP profile property: jstart/bootstrap = [yes/no] • Internal default value: yes Trace Level • The trace level is configured in the instance profile; it can be overridden for the Java instance controller with this argument. • Program argument: -tracelevel=[0..3] • SAP profile property: jstart/TRACE = [0..3] or rdisp/TRACE = [0..3] • Internal default value: 1 Special Command Line Arguments • The following command line arguments are used by the JSTART processes to configure the runtime behavior or to tune some specific properties and options. • Note: You cannot use these command line arguments to configure the Java Startup Framework. These arguments are documented here for trace file analysis only.

28. Special Command Line Arguments Shared Memory Node ID • The Java instance uses shared memory for administration, monitoring and session management. Each process that accesses this shared memory needs a node ID that identifies the process and assigns a part of the shared memory for status reporting. • Program argument: -nodeId=<shared memory ID> • Internal default value: -1 (no relation to a shared memory segment) Java System Properties • The Java VM provides a set of system properties, which can be extended during Java VM initialization. This command line argument is added to the initial set of Java system properties. It may occur several times with different <name>=<value> pairs. • Program argument: -hostvm • Internal default value: —D<name>=<value> Operation Mode • The JSTART program can operate in three different modes: Java instance controller, Java launcher, or host process for a Java VM. This argument assigns the Java VM host mode. • Program argument: -hostvm • Internal default value: depends on the presence of several other command line arguments if the mode is not explicitly assigned Node Name • The node name specifies the section in the node definition file that defines the node. This (technical) name may differ from the (visible) name of the node in the trace file and the management UIs • Program argument: -nodeName=<node name> • Internal default value: none Node Definition File • This file contains the parameters for the node being represented by the JSTART process. • Program argument: -file=<file name> • Internal default value: none

29. Special Command Line Arguments Java SDK Configuration File • When JSTART operates as a Java instance controller or Java launcher, it analyzes the Java SDK defined in the node definition and instance profile. It then stores the results in the Java SDK configuration file and shares them with the Java host processes. • Program argument: -jdkFile=<file name> • Internal default value: none Developer Trace File • The name of the developer trace file. More information: Developer Trace and Log Files. • Program argument: -traceFile=<file name> • Internal default value: none, trace messages are written to the standard output stream Detailed Protocol in the Trace File • This option controls the output of the command line options and arguments passed to the child processes, Java VM and Java main method. • Program argument: -protocol=[on/off] • Internal default value: jstart/protocol Java VM Output Redirection • This option allows you to redirect the standard and error output of the Java VM to a specified file. • Program argument: -jvmOutFile=<file name> or -javaOutFile=<file name> • Internal default value: none Activate Debug Mode • This option activates Java debugging with the debugging agent. It is used to enable debugging with Java VMs from other vendors • Program argument: -debugMode=[yes/no] • SAP profile property: jstart/debugMode • Internal default value: no Additional Environment Settings • This option allows you to add environment settings to JSTART. The value has to be in the format: envvar1=value;envvar2=value;… • Program argument: -environment=<list of environment variables> • SAP profile property: jstart/environment • Internal default value: none

30. SAP Profile Parameters • The instance profile contains the important SAP profile parameters used by the JSTART program. These parameters apply to the whole AS Java instance. The file is located in /usr/sap/<SID>/SYS/profile/<SID>_<instancename>_<hostname>.

31. SAP Profile Parameters

32. SAP Profile Parameters - 1

33. SAP Profile Parameters - 2

34. SAP Profile Parameters - 3

35. SAP Profile Parameters - 4

36. For Further Info http://help.sap.com/saphelp_nwce71core/helpdata/en/e1/b5443e02a9ab4186a6e1240a9a2455/frameset.htm