S4 SAP 1809 SP01

SAP FIORI for

S4 S4HANA
ASCS00/PAS01 saps4qap01 [Link] A0N5US084XVM057 App
Q SAP IBP S/4HANA
INTEGER 1.0 (SCM
Blackline
S4 SAP 1809 SP01
SAP FIORI for
S4
00 - AAS S4HANA saps4qap02 [Link] A0N5US084XVM065 App
Q
SAP IBP S/4HANA
INTEGER 1.0 (SCM)

…..

What’s new in SAP NetWeaver 7.3 – A Basis perspective 

Instances Naming convention

As of SAP NetWeaver 7.1, the concept and naming of SAP system instances has changed. The
terms “central instance” and “dialog instance” are no longer used. Instead, the SAP system consists
of the following instances:

 Application server instances

Application server instances can be installed as “primary application server instance” (PAS) or
“additional application server instances” (AAS).

 Central services instance

 Database instance
The Central Services Instance ABAP – ASCS
The central services instance for ABAP (ASCS instance) is now installed with every SAP ABAP
system distribution option:
❶ Standard System      ❷ Distributed System      ❸High-Availability System
The enqueue replication server instance (ERS instance) can now be installed together with the
central services instance for every installation :

 Standard System (optional)

 Distributed System (optional)
 High-Availability System (mandatory)
At the time of SCS installation if we can select the above option it will install ERS instance as well.

Though I am such a naive person who is failed to understand the purpose of having ERS instance
on same host where we are having Enqueue server.

5. The Central Services Instance ABAP – ASCS

With new Installation Master for ABAP+Java, SAPInst does not provide option for separate ASCS
and SCS Instance.  Though it can be separated manually after installation on different host.

6. Split Off ASCS Instance

SAPInst now has an option to “Split Off ASCS Instance”

With the option Split Off ASCS Instance from Existing Primary Application Server Instance, you can
split off an central services instance for ABAP (ASCS instance) from the primary application server
instance of an existing ABAP system or ABAP+Java (dual-stack) system.
Solution Manager Key

As of SAP NetWeaver 7.3, Solution-Manager-Key at the time of Installation is not asked/required by

SAPInst.

Even in previous installation people found out the way to generate the Solution Manager Key out of
SolMan System.

Start Profile Merged

As of SAP NetWeaver 7.3, Start Profile has been removed as separate file.

In earlier versions of NetWeaver there were 1 Default profile per SAP system, 1 Start profile per
Instance and 1 Instance profile per instance.

Now the Start profile contents are merged with Instance profile. With help of new Instance profile
SAP processes are started and at the same time instance specific parameters are read.

This removed total number of profile files. 1 Default profile per SAP System, 1 instance profile per
instance.
Visual Admin Vs NWA

As of SAP NetWeaver 7.1, Visual Admin has been replaced with NWA

Support Pack Stack

Earlier in NetWeaver 7.0, For a Support Pack Stack the  release level of BW component was
generally  2 release ahead of the ABAP and Basis component.

Now all components are  released on same level.

From NetWeaver7.1 sap introduced new tool in place of JCMON. This tool is JSMON

This can be used just like jcmon.

jsmon pf=<instance profile name>

you can type help and get multiple options that can be used, like below screenshot you can type
instance, process, display and see the result.
 PAS stands for the primary application server.

AAS stands for the additional application server.

ABAP Central Services (ASCS) is the core SAP application service. It consists of following servers:

 Message Server: works as a load balancer. All user requests are first processed by the
message server and then distributed to each SAP application server.

 Enqueue Server: manages lock table. To prevent different operations from modifying a
record at the same time, the table is locked to ensure data consistency.

The differences between the PAS and a AAS: The PAS contains the ASCS, but an AAS does
not. In a system, there is only one PAS, but there can be multiple AASs. The number depends
on the service requirements.
 If any problem occurs in the ASCS, the entire SAP system breaks down. Therefore, adopt the HA
architecture for the ASCS.
How to check ASCS from OS level - here 00 is instance number for ASCS

If you change instance number for AAS then it will show AAS instance, see below

Useful sapcontrol command to check Status of Application server

 sapcontrol -nr 00 -function GetVersionInfo.
 sapcontrol -nr 00 -function GetProcessList.
 sapcontrol -nr 00 -function J2EEGetProcessList.
 sapcontrol -nr 00 -function GetSystemInstanceList.
You can check form SAP GUI that all the instance is up and running fine or not

Login with SAP GUI –

T Code – SM51
Check work process from OS level – DPMON command

Dpmon pf=<Instance profile>

Every work process defines and parameterized in respective profile.

SAP Profile: will discuss later after architecture

SAP System Architecture

Figure 1 – Different SAP System Architectures

In the three-tier SAP architecture, the presentation tier provides the interface to the
user, the application tier processes the business logic, and the database tier
stores the business data.

The Presentation Tier

The presentation tier is typically located on PCs of business users and provides the
SAP Graphical Interface (SAP GUI). SAP GUI is a lightweight application that can be
installed on any computer running MS Windows or Mac OS and it provides the interface
for communication between the user and the SAP ERP system.

The Application Tier

The application tier is basically the heart of the SAP ERP system. It executes the
business logic, responsible for processing client transactions, print jobs, running reports,
coordinating access to the database, and interfacing with other applications. It is
possible to distribute the application logic between several server machines in situations
when the load exceeds processing power of a single server.

The Database Tier

The database is used for storing two types of objects: the business-generated data and
the SAP application programs. The business-generated data represents data objects
created by users as part of various business processes. For instance, sales orders or
customer master records are classified as the business-generated data. SAP
application programs are routines written in ABAP (special programming language used
in SAP) that are loaded into the SAP application servers from the database at runtime.

It is possible to use databases from different vendors (for instance, Oracle or Microsoft)
and it is up to the company to decide which database vendor to choose. Usually, the
database license is included into the price of SAP. The database tier has the highest
requirements for availability, reliability, and performance because usually each SAP
system is deployed on one database instance. Therefore, performance of the database
tier ultimately determines the scalability of the entire SAP ERP installation.

Figure 2 – SAP ERP Application Modules

Although SAP application modules cover completely different business process and
business areas, technically they work in a similar manner. The difference is only in
ABAP programs and data tables that are used in each of these modules of SAP. For
this reason, our article is not going to focus on any particular SAP module but will
instead explain how does SAP work with the three-tier architecture in general.
How Does SAP Work?

Now that we know what are the components and tiers of the SAP ERP system, let us
see how does SAP work. As it was explained above, the heart (or kernel) of the SAP
system is in the application tier (application server). The application server gets input
from and displays output to the presentation tier (SAP GUI). Furthermore, it stores data
in the database tier.

Each SAP instance contains a dispatcher and several work processes. The dispatcher
distributes tasks to one of the work processes. The SAP system has different kinds of
work processes that were created for various tasks. Here is the list of their types:

 D: Dialog work processes which are responsible for handling online transactional
requests from users.
 B: Batch work processes which are responsible for processing background jobs
scheduled in the SAP system.
 V: Update work processes which are responsible for carrying out updates in the
database. These updates can happen asynchronously to batch and dialog processes.
 S: Spool work processes which are responsible for enabling printing in the SAP system.
 G: Gateway work processes which are responsible for enabling communication between
applications (for instance, between SAP R/3 and SAP R/2). Only one gateway work process
is needed per one SAP system.

how Does SAP Work?

SAP system works in the following way:

1. A request arrives from the presentation tier (it can be an online request from a user or a
request related to a batch job or anything else).
2. This request is analyzed by the dispatcher of the SAP central instance.
3. The dispatcher passes the request to the message process (M).
4. The message process (M) decided whether this request should be processed on this
instance or needs to be forwarded to a different instance (for example, an instance with a
lower computing load).
5. If the request remains at the same instance, it is put in one of the work processes of the
appropriate type (for instance, if it an online request from a user, it should be placed in the
dialog work process).
6. The request gets processed by the work process, and if necessary, the SAP system will
commit an update to the database through the enqueue server (E).
7. The feedback about outcome of the request is delivered back to the originator of the
request in a reversed order.

This explanation of how does SAP work could be a little bit difficult to follow, and
therefore, let us consider a simple example that will hopefully make understanding
easier.
In our example, a business user runs a transaction called ZREPORT (it a fake
transaction just for this example). This transaction selects one customer from the table
with customers and changes its name. We are interested to see what happens in the
SAP ERP system when the business user executes this simple transaction. Figure
5 provides an illustration of how SAP works in this example.

Figure 5 – How Does SAP Work (Example)

According to Figure 5, the SAP ERP system receives input via SAP GUI from a
business user. This user launched the transaction. Next, the system process this input
in a number of steps:

1. The input is passed to the dispatcher of the central instance.

2. The dispatcher passes the request to the message process (M).
3. The message process (M) placed the request into one of the dialog work processes (D).
4. The dialog work process (D) performs reading and update of the database through the
enqueue server (E).
5. The enqueue server (E) passes the update request to the database (it is necessary to
update name of the customer).
6. The database returns feedback to the dialog work process (D).
7. The dialog work process (D) passes the feedback to the dispatcher.
8. The dispatcher returns the outcome of the operation to the presentation tier (SAP GUI)
and the business user sees the result on her screen.
Hopefully, this simple example will help you to understand the general principle of how
does SAP work. Of course, in the real life, there are millions of technical details and
nuances that are only known to SAP basis experts. Nevertheless, this explanation
should be a good starting point for everyone who wants to understand the basic
technical principles of how does SAP work.

SAP Profile: -

SAP Profiles (System Profiles) contain parameters that specify how to startup an instance and how-to setup the
various variables that define the way the SAP instances and system work.

 Path: <SAPMNT>\<SID>\SYS\profile\
 Exampl[Link]\usr\sap\DEV\SYS\profile\
The profile file is structured as follows:
# This is a comment in an SAP profile:
Parametername1 = Value1
Parametername2 = Value2
Parameter names that logically belong together have a common root. For
example, the root of parameters that control the dispatcher within an
application server is: rdisp/.

The parameter rdisp/wp_non_dia specifies how many dialog

work processes are started by the dispatcher.
The SAP profiles are stored in a special file directory. This directory
can be made accessible from all hosts, depending on current
requirements.
UNIX systems:/usr/sap/<SID>/SYS/profile
 Microsoft Windows NT
systems: \\<SAPGLOBALHOST>\sapmnt\<SID>\sys\profile
\

More [Link]
 Basic start-up troubleshooting – the logical
sequence!

Basically when you start the system…

Database starts

SAP checks if the database is available and if it is not it starts the database. No dedicated developer
trace is created in the work directory as the database has its own logs.  If the database does not
start correctly it should be visible within seconds.

Message server kicks in

The message server is the first part of the system to start, it handles the communications between
the instances.  Only one message server is available per system, regardless of the amount of dialog
instances available. The message server logs are kept on the dev_ms developer trace and if there is
an issue with the message server it will be pretty obvious because you will not see a dev_disp trace.

Dispatcher next

The dispatcher job is to receive the requests and direct them to an available suitable work process.
During start-up you can see how the work processes are invited to start in the dev_disp developer
trace. If something was to go wrong the only thing you will find in dev_disp is that the work
processes died. Usually no reason is ever given for the failure to launch in this trace, but one dev_w*
developer trace for each dialog process is created and populated in the process.

The dialog processes

This is where you’ll find the root of the problem 99.9% of the time. Why?…  Each dialog process has
a dedicated memory area and a dedicated connection to the database layer. If something is going to
go wrong it will most likely happen here. Each work process has its own developer trace dev_w*
where you will find detailed information on the error.

So the logical troubleshooting sequence, in a nutshell is…

 Check connection to the database with a quick R3trans –d command, it’s the quickest and
simplest way to discard DB availability as the issue.
 Go to the work directory and check the developer traces. If the dev_w* logs exist it means
that the message server and dispatcher started and the issue is in the work process logs..
 If the dispatcher and work process developer traces are not created then your issue is in the
message server developer trace.

The next time you find a start-up issue I’m hoping that these simple steps might mean we can
dispense with the crystal ball 
Basic start-up troubleshooting JAVA – the
logical sequel!

Database Starts

As on ABAP the first step is to check and start the database. No dedicated developer trace is
created in the work directory as the database has its own logs.  If the database does not start
correctly it should be visible within seconds and errors will be available within the DB logs.

Developer traces: Refer to your DB logs.

Startup

JSTART is called next, it takes the role of the Java instance controller which analyzes its
configuration and initializes SAP signal handling and opens the control port.

There is very rarely an issue with the initial load of JSTART. If for some reason this fails you most
likely have a problem with your instance profile.

Developer traces: dev_jstart

Offline Deployment

The Java instance controller reads the instance definition and creates a child process that initializes
JVM and starts the OFFLINE DEPLOYMENT program which performs the deployment steps in the
Java database.

In the ‘business as usual’ scenario this is very unlikely to end up in an error. These days most
deployments are done automaticaly using SUM, the traces will be filled when the instance is stopped
and started during the SUM deployment phase.

Developer traces: dev_deployment, std_deployment.out and jvm_deployment.out

Bootstrap

BOOTSTRAP synchronizes the binary data in the Java database with the local file system.

This is where you will most likely find issues during your system startup. Errors during this phase are
common and usually caused by issues in one of the following areas;

1. Problems at DB Level

There is a large number of reasons for this to fail going from DB availability to problems with
listeners and DB user authentication.

Bootstrap Stops Due to Database Problems – Configuration of SAP NetWeaver – SAP Library

2. Problems at the File System Level

 Problems with environmental variables, file permissions, file availability, mounts, etc…

Bootstrap Stops Due to File System Problems – Configuration of SAP NetWeaver – SAP Library

3. Problems at the Configuration Level

Java VM settings configured incorrectly, usually related to memory allocation.

Bootstrap Stops Due to Configuration Problems – Configuration of SAP NetWeaver – SAP Library
Developer traces:dev_bootstrap, std_bootstrap.out and  jvm_bootstrap.out
Internet Communication Manager (ICM)

The Java instance controller starts the processes for infrastructure nodes – the most important in my
opinion is ICM; ICM handles the HTTP request directed to the AS JAVA system.

If there is an issue with ICM you’ll see an error on screen while calling the java standard
URL. [Link] you will also find the details on the ICM developer trace.
Developer traces: dev_icm
Server Node

When all infrastructure processes are started, the Java instance controller starts the processes for
the server nodes.

Finally, your Java system is running and if there was an issue with any request dealt with by this
server node you will find information about it on the developer trace.

Developer traces: dev_server0, std_server0.out and jvm_server0.out

Hope this is a good basic explanation of where to start when troubleshooting a Java Startup
problem!

As a reference I have taken the freedom to borrow this lovely chart from SAP Help to ilustrate my
case
 

If the sap system is down where will you start trouble

shooting?
Sometimes users may complain that they are :

i)       Unable to login to SAP system from SAPGUI

ii)      Other users who have already logged in may complain that system is not responding
iii)    Some users who have already logged in may complain that system is very slow and response
time is very high

Please note that in most of the above cases even SAP basis
administrator cannot login to SAP system through GUI. So, he should
use database, operating system tools (like PuTTy) and dpmon to
identify the issue and troubleshoot.

If SAP system is down, then we start trouble shooting at OS level. Once it is done then we check for
DISP+WP this is the main source where failure occurs. Check whether DISP+WP is active if it is
active then SAP system is up and if DISP+WP is inactive then it means the SAP system is down.

1. Some critical filesystem at Oslevel is full and system is not able to

perform any activity due to that. Within a while all the dialog work
processes are full, and no other user is allowed to login

Solution:  As even administrator cannot login through SAP GUI at this point
of            time, please check at oslevel whether any filesystem is 100% full. If so,
please contact OS team and make sure sufficient space is free either by requesting
them to add more space or by deleting some unnecessary files

You can check dispatcher, message server, dialog work process related logs in work directory.

SAP SYSTEM MONITORING: