SAP Host agent auto upgrade procedure

We should maintain latest version of saphostagent in sap environment as solman gets the info from satellite systems wit the assistance of saphostagent.

This topic is to point out the feature to upgrade saphost agent automatically without manual intervention.
Only thing is we'd like to form sure the SAR file is downloaded and staged within the auto_upgrade directory.

Procedure to enable Auto-Upgrade feature for SAP Hostagent

SAP Hostagent has an auto upgrade feature which may be enabled as per note 1473974.


Please add the subsequent Parameters to SAP Hostagent Profile file for Linux (/usr/sap/hostctrl/exe/host_profile).


hostexec/autoupgrade_delay = 1440

DIR_NEW = //SAP/SAPHOSTAGENT/Linux/auto_upgrade

service/EnableRemoteDeployment = true

service/protectedwebmethods = NONE


1440 in hostexec/autoupgrade_delay is mentioned in minutes which translates to 24 hours (24*60 = 1440)


For Windows and HP-UX, use below paths present.

*DIR_NEW=//SAP/SAPHOSTAGENT/HP-UX/auto_upgrade

*DIR_NEW=//SAP/SAPHOSTAGENT/Windows/auto_upgrade


Note: Please restart Hostagent with below command for the parameters to require effect.


As root

Change to below dir

/usr/sap/hostcontrol/exe

./saphostexec -restart


If these parameters are activated, Hostagent automatically takes care of the upgrade by checking the trail mentioned in DIR_NEW and initiated an upgrade automatically when there's a replacement version available in this directory.

SAP GUI SNC Configuration

Below mentioned configuration is essential to enable the secure network communications (SNC) between SAP GUI and SAP ABAP systems.

Prerequisites:

Along with SAP BASIS related transcations, we'd like below additional transactions.

SNCCONFIG

SNCWIZARD


We also need below details

SAP System ID

Fully qualified message server hostname

Installation number

CommonCryptoLib version must be at least CommonCryptoLib 8.5.2.

snapshots of SAP instance, default profiles,SNCCONFIG and STRUST settings.

Transaction RZ10 > Import the most recent version of profiles

Take backup of profiles at OS level

Procedure:

Configure SNC

Transaction RZ10 > Import the newest version of profiles

Transaction SNCWIZARD


Continue

Copy and paste the details like  SNC identity parameter generated by the wizard here:

p:CN=, OU=, OU=SAP Web AS, O=SAP Trust Community, C=DE


Replace the parameter value with the subsequent format, per your client CA requirement:

p:CN=, OU=, L=, O=, SP=, C=, EMAIL=<email>

Please note:

The message server host is defined within the SAP Logon pad. 

The installation number, OU=, is unique to each SAP environment. 


Continue

Continue

Continue


If you are prompted to configure Kerberos Credentials, click on Skip.

Continue


Transaction STRUST opens in a separate window.

Expand folder and double-click on SNC SAPCryptolib

The self-signed SNC SAPCryptolib certificate created via SNCWIZARD earlier occurs here.

Click on to Create Certificate request

Select all and replica the certificate (without empty lines)

Paste in Notepad (without empty lines) and reserve it as “_SNC.csr”.
Exit transaction STRUST and return to SNCWIZARD

Complete

Request client signed certificate

Update DEFAULT.PFL

While expecting the signed certificate, update the subsequent parameters in DEFAULT.PFL.


Verify the file libsapcrypto.so exists on the OS level, in /usr/sap//SYS/exe/run directory.

Transaction RZ10

Parameter Required value

snc/gssapi_lib usr/sap//SYS/exe/run/libsapcrypto.so

spnego/enable 0

Save changes.

Need to restart SAP application once parameter changes are done.. 

Import client signed certificates (*.p7b file)

Double-click to open the *.p7b file


Expand certificates

It contains 3 certificates - Issuing, Root & Server.


All 3 certificates must be exported and combined in a single text file. Here is how …

Right click on the server certificate “<host>.<domain>.com” > All Tasks > Export in Base-64 encoded X.509 format, save each *.cer to your desktop location.


Next

Select “Base-64 encoded X.509 (.CER)” > Next

File name = Next

Finish

OK


Repeat an equivalent steps above to export "root" and "issuing" certificates

Close the certmgr screen.

Open each *.cer file with Notepad, combine all 3 certificates into 1 document , during this specific order - server, root and issuing.

Delete any extra empty lines or carriage returns.

Then, save as a text file. For example: __signed.txt



Login to SAP system

Execute transaction STRUST

Click on to switch to change mode


Expand folder and double-click on SNC SAPCryptolib

Under Own Certificate, select "Import certificate response"


Copy and insert the certificate chain - server, root & issuing, confirm there are not any empty lines at the start and end of the file.


Continue

SNC certificate is now signed.


Click on to save changes.


Restart SAP after succesful  SNC configuration, Update the GUI entry and test SNC connection.

BW on HANA migration procedure

BW on HANA important SAP links

Below Links are considerably useful to urge the complete information on preparation, execution and post processing. Please undergo the links and obtain an summary on BW on Hana migration.

http://scn.sap.com/community/hana-in-memory/blog/2014/02/25/where-to-find-information-on-sap-bw-on-hana-migrations

http://scn.sap.com/community/netweaver/blog/2015/01/06/migrating-sap-bw-to-sap-bw-on-hana--a-guide-for-sap-basis-architects--part-1-the-workshop

https://scn.sap.com/community/standards/blog/2014/03/23/bw-on-hana--pre-migration-activity

http://scn.sap.com/community/bw-hana/blog/2014/02/19/bw-pre-and-post-upgrade-and-migration-tasks

http://sapinsider.wispubs.com/Assets/Blogs/2013/June/76-steps-in-a-BW-to-HANA-migration-Workplan

https://www.sap-press.com/implementing-sap-bw-on-sap-hana_3609/

http://scn.sap.com/docs/DOC-7856

Connection to partner 'sapserver:sapdp00' broken (NIPING); WSAECONNRESET: Connection reset by peer

Below info is used for troubleshooting intermittent connection issues with in SAP system.

In general, intermittent connection loss occurs with below two reasons

1.      If there is a crash in the dispatcher process of the instance to which the client was connected.

2.      Network Problems (Firewall idle timeout, Black Hole Router, VPN, WAN problems)

For first case, if there is a crash with dispatcher process, This triggers a TCP package with an activated RST flag, which is sent to all connected communication partners and triggers the error message described above in the SAP GUI, among others. All connections will then automatically broken.

For second case, regarding network problems, we need to perform checks with NIPING which tests the performace of packet transmission in TCP layer.

NIPING generally checks the packet transmission in TCP layer of the network where all SAP transactions takes place.

we may not see any packet loss while we ping the servers from terminal and  vice-versa. but if you see errors in NIPING trace, you need to fix it based on the error. Mostly it will be of network issue and some times it may be due to OS.

To check the connectivity using NIPING tool, We need to start NIPING server at SAP level and trigger the NIPING packet transmission from the frontend terminal.

Use below commands

To do this test, it is required to start NIPING as a server in one host:

> niping -s -I 0 -T NIPING_SERVER_TRACE

In the remote host is is required to start NIPING as a client:

> niping -c -H <SAP HOST NAME> -X3 -B 10 -D 30 -T NIPING_CLIENT_TRACE

Also check dispatcher logs of all the application servers.

we need to get below details from the user

• SAP GUI version and patch level
• Windows version and patch level
•  If they had done any upgrades at frontend like windows and sapgui
•  If they are facing issue with any particular transactions or for every transactions
•  If they are facing issue during particular time
•  How are they connected to SAP system, using any VPN or direct client network
•  Are they facing issue with SAP only or with any other applications are also crashing
•  If they are using wired connection or wireless.

Incorrect SLD security role assignments after upgrade

If you experience SLD permission issues after an upgrade for users that worked fine before the upgrade, confirm that each one SLD roles are configured properly. This can be done in the following manner:

 1. Log on to http://:/useradmin of the AS Java hosting your SLD.

2. within the search criteria select the entry "Role" from the dropdown menu and enter "SAP_SLD_*" as a filter.

3. Perform the subsequent steps to see the configuration of every SLD role consistent with the small print within the attached Word document:

 a) Select a role.

 b) within the details pane, select tab strip "Assigned Actions".

 c) Compare the assigned actions with the list of actions defined in the Word document.

 d) If one or more actions are absent, click button "Modify" and add the missing actions.

 e) Save any changes you made.

 4. Log on to http://:/sld,

navigate to "Administration" - "Settings" and click on the button "Perform Role Mapping".

This will refresh the mapping of SLD UME roles to SLD user groups to make sure that this mapping is correct, too.

PI service users locked

PI service users comes default with the installation and exists along side the password within the client of Integration server and exchange profile.
They are utilized in the PI environment for dialog free communication between central components of Netweaver usage type PI and also between app servers and PI

Below are the roles assigned to them

Service User	Description	Assigned Role
PILSADMIN	User for the Change Management Server	SAP_XI_CMS_SERV_USER
PIREPUSER	User for the Enterprise Services Repository	SAP_XI_IR_SERV_USER_MAIN
PIDIRUSER	User for the Integration Directory	SAP_XI_ID_SERV_USER_MAIN
PILDUSER	User for the System Landscape Directory (SLD)	SAP_BC_AI_LANDSCAPE_DB_RFC
PIAPPLUSER	User for sender applications	SAP_XI_APPL_SERV_USER
PIRWBUSER	User for the Runtime Workbench	SAP_XI_RWB_SERV_USER_MAIN
PIAFUSER	User for the Advanced Adapter Engine	SAP_XI_AF_SERV_USER_MAIN
PIISUSER	User for the Integration Server	SAP_XI_IS_SERV_USER_MAIN
PIPPUSER	User for principal propagation	SAP_XI_APPL_SERV_USER

These users will be maintained in different connections and transactions. Inorder to change the passwords, we need to change them in all those connections and transactions.

There is a typical procedure to vary the passwords of those users provided by SAP.


We need to follow the procedure from below notes for changing the passwords supported your PI version.

999962 - PI 7.10 and higher: Change passwords of PI service users

2474153 - How to change passwords of PI service users in Java Only PI system

936093 - PI: Change to passwords of PI service users

721548 - XI 3.0: Changing the passwords of the XI service users

Client deletion procedure

Client is a business unit in SAP system. we can see three standard clients which usually comes with the installation of SAP system. 000,001 and 066

066 is early watch client and now a days it's of no use as solman is mandatory.
So in such cases, we may have to delete the clients 066 and 001.
Below is the procedure for deleting client.

Client deletion through scc5

First log within the client you'd wish to delete with username as SAP* and password as pass if you're logging into that client for the primary time.

Use transaction code SCC5 and select the check box which says Delete entry from T000 and click on start immediately... you will get the prompt if you can continue, click continue and wait till it deletes the client.

 Once the client is deleted, login to 000 Client and issue the transaction code SCC4 to see if the deleted
client is listed within the list or not... If it's unlisted then you've got successfully deleted a client.

Client deletion through R3trans

1)logon to system as SAP Admin

2)goto /user/sap/trans/bin dir

3)use standard editor to create a control file
 with ctl ext(eg. delcli.ctl) with following text
 clientremove
 client=xxx
 select*

4) run the commnd on command field
 r3trans -w delcli.log -u1delcli.ctl

Notes regarding client deletion

Note 70643 - CC-TOPIC: Client Deletion (SCC5)

Note 35952 - Client deleted, space still filled in database

Reprocessing and Deletion of IDOC

IDOCs are Intermediate Documents which are used for the communication between two SAP systems which can be having the encoded data which SAP system only can read.

IDOCs will be getting transferred between SAP systems and will sometime fails due to the lack of resources or due to queue stuck etc.

In such situations, we'd like to reprocess the idocs. Below are the steps which shows us to re-process/flag the IDOCs in SAP system.

How to reprocess an Idoc:

1. Go to transaction BD87

2. Enter Idoc number, and make sure the dates are correct

3. Click the Execute button or press F8

4. To reprocess, select the Idoc status within the "IDOC in inbound processing" tree.

5. Click the Process button

6. the subsequent screen will give the status of the IDOC and wheter it processed sucessfully

How to flag an Idoc to be deleted:

1. Go to transaction BD87

2. Enter Idoc number, and make sure the dates are correct

3. Click the Execute button or press F8

4. To delete, select the Idoc status within the tree and click on EDIT -> RESTRICT AND PROCESS

5. Click the Execute button

6. Un-check the Bkgd Processing checkbox.

7. Click the Execute button

8. Click the Delete Flag button.

Administration of IDoc Communication

IDoc communication is predicated on transactional Remote call (tRFC).

You can optimize the performance of ALE processing by using the subsequent settings and procedures.

Suppressing Background Processing
If tRFC errors occurs in the standard SAP system, , a background job is generated to re-establish the connection. In certain circumstances this might end in an outsized number of background jobs being started that completely block backgrounding .

Note:
Use program RSARFCEX to restart tRFC to cancel a background job if tRFC errors occur .

Select a connection to change in ALE Customizing (transaction SALE), 

Communication

Create RFC Connections (SM59)

Choose Destination ® tRFC Options and select the option Suppress Background Job at Comm. Error.

Setting Dispatch Status to OK
When an IDoc is passed to the communication layer, it's assigned a globally unique transaction identifier (TID). If the IDoc has been successfully dispatched, this information isn't automatically passed to the ALE communication layer. So that ALE processing sets the IDoc status to Dispatch OK, you ought to compare the TID numbers within the communication layer and therefore the ALE layer.

The SAP program RBDMOIND checks that the IDocs passed to the tRFC have already been sent to the receiving SAP system. If they need been sent, the IDoc status is modified to "12" - Dispatch OK

Note:
To set the IDoc dispatch status, run the program RBDOIND after the IDocs are passed to the communication layer.

Checking the tRFC Status

Use
Transactional RFC calls which transfer IDocs use the function module IDOC_INBOUND_ASYNCHRONOUS at reception (before release 4.0: INBOUND_IDOC_PROCESS).

If an IDoc in the sending system has been passed to tRFC (IDoc status "03"), but has not yet been input in the receiving system, this means that the tRFC call has not yet been executed.

Activities
To check the status of the tRFC calls, select Tools -> IDoc Interface/ALE -> Administration -> Monitoring -> Troubleshooting -> RFC Queue (SM58) and setout any additional selection criteria.

The program RSARFCEX restarts unsuccessful tRFC calls.

Note:
You cannot choose the choice is being executed in backgrounding .

PI configuration notes

SAP PI/PO is the Module which integrates all the SAP modules where it acts as a mediator or for interpretation between different SAP systems and also between SAP and Non SAP systems.

Generally PI/PO systems will not be refreshed and it is very complicated.

If we get in to a situation to refresh PI/PO system, below info will be helpful.

Here are couple of notes for PI post configuration

PI SLD Self Registration - SAP Note 1439558

7.10 SP5 Patch 8, 7.11 SP1 Patch 0, 7.30 SP0 Patch 0

PI Demo Client - SAP Note 1304208

7.11 SP0 Patch 0, 7.30 SP0 Patch 0

PI Full Qualified Host Name - SAP Note 1320707

7.11 SP1 Patch 0, 7.30 SP0 Patch 0

PI Adapter Engine in Java Proxy Runtime Mode - SAP Note 1346933

7.11 SP4 Patch 0, 7.30 SP0 Patch 0

PI Robustness Configuration - SAP Note 1400543

7.30 SP0 Patch 0

PI Single Sign-On Configuration - SAP Note 1473556

7.30 SP1 Patch 0

PI Self Test for SAP NetWeaver - SAP Note 1286149

PI Wizards Overview - SAP Note 1286428

Performing a PI system copy SAP Note 1299373

Configuration Wizard: SAP Note 1400543

Parameter description SAP Note 1375656

Correcting the CALL_FUNCTION_SECSTORE_ERROR short dump

This information is for troubleshooting the short dump CALL_FUNCTION_SECSTORE_ERROR.

The system cannot read the password of the required RFC connection from the secure storage, or the password doesn't exist within the secure storage.

Use transaction SECSTORE to see the status of the secure storage.

If this seems correct, select the application "RFC Destinations" and search for the destination /RFC/.

The destination entry should have a green indicator.
If it doesn't , the message text column displays information about the error.

You can use the question mark within the end column to get an in depth description of the error and notes fix it.

If the destination /RFC/ is not listed in the secure storage, the password is lost.

If this happens, you'll use transaction SM59 "Configuration of RFC Connections" to reenter that password.

Once we save the destination, the status of the password (PW-Status) should be set to "saved" and a corresponding entry should be available in transaction "secstore".

PI POST INSTALLATION STEPS

After a PI installation you have to configure your system. 
This is a mandatory post installation step called "Running the Configuration Wizard".
Before running the Wizard, it is recommended to update the following Java Software Components (SCs) to the highest available Support Package and Patch Level:
Life Cycle Management:

LM CONFIGURATION (LMCFG)
LM CONFIGURATION WIZARD (LMCTC)

Process Integration:
    MESSAGING SYSTEM SERVICE (MESSAGING)
    XI ADAPTER FRAMEWORK (SAPXIAF)
    XI TOOLS (SAPXITOOL)
    PI GUI (SAPXIGUI, only 7.11)
    PI GUILIB (SAPXIGUILIB, since 7.30)
    ESR (SAPXIESR)

The ABAP stack must have the same Support Package level as Java.
This Wizard Template is available since Release 7.10.

A prerequisite to run the Wizard is that the system was installed with the PI Installer (SAPInst). All PI services must be up and running.
For further information about the Configuration Wizard, see the following collective notes:

    SAP note 0923359 - Collective Note: Configuration Wizard (Release 7.0x)
    SAP note 1107808 - Collective Note: Configuration Wizard (Release 7.1x)
    SAP note 1362909 - Collective Note: Configuration Wizard (Release 7.3x)
    SAP note 1286428 - Configuration Wizard: PI Wizard Templates overview (Releases 7.1 and higher).

Solution
To run the CTC Wizard, start the SAP NetWeaver Administrator and navigate to "Configuration Management --> Scenarios --> Configuration Wizard". Depending on your release do the following:

Releases 7.10 / 7.11:
In the drop down list, please choose "Initial Configuration" or "All Configuration tasks -> NetWeaver initial setup".

Releases 7.30 / 7.31 and higher:
Click on link "Functional Unit Configuration UI". Select Functional Unit "SAP NetWeaver Process Integration (PI)". All required Functional Units are selected automatically. Press button "Enable automatically" to start the CTC Wizard.

Oracle shutdown types

During a normal shutdown, Oracle closes all sessions . closes the database, un-mounts the data files then shut down the instance in two steps, first issuing a "free" the SGA RAM heap and eventually , terminating the background processes.

Oracle has three shutdown modes:

Normal (default) - waits for in-flight work to finish . This could take houes.

Immediate - terminates all sessions and rollbacks all uncommitted transactions. 

Abort - it aborts all sessions, leaving current DMLs for rollback and de-allocates the SGA terminating all the background processes. Note that a shutdown abort isn't dangerous. The "abort"  means Oracle will terminate all active work, which is what most of the people want during a shutdown!

The "normal" and "immediate" modes can take an extended time in you've got in-flight transactions, and lots of Oracle DBA's ensure a swift clean shutdown this manner , aborting the sessions, re-starting to allow warmstart rollback of the aborted transactions, and a shutdown immediate to shut cleanly:

SQL> shutdown abort
SQL> startup
SQL> shutdown immediate

Normal Shutdown:
A normal shutdown of an Oracle database is really rarely used. This is because the normal shutdown waits for everybody to finish their work then logoff in an orderly fashion. When a normal shutdown occurs, the database is closed in a normal manner, and all changes made within the database are flushed to the database datafiles . This is known as a “clean shutdown.”

It will simply wait forever until we  kill those sessions manually. Because of this, we frequently recommend the shutdown immediate or shutdown abort commands, which we'll discuss within the next sections. Below is the syntax for the utilization of the normal shutdown command.

SQL> shutdown

When shutdown is executed , Oracle flushes all the changes in memory out to the database datafiles . This makes database startup quicker because the database is during a consistent state.

 A clean shutdown is one that's prepared to return copy at once . A dirty shutdown is one that lands on its back; it can't come up without first recovering itself.

Shutdown Immediate:
Perhaps the simplest way to initially shutdown the database is that the shutdown immediate command. This command will prevent any new logins, then rollback any uncommitted transactions, then bring down the database. In the process of bringing down the database, Oracle will flush all the changes in memory bent the database datafiles too, a bit like a daily shutdown does. This makes database startup quicker. Below is the syntax for shutting down a database with the shutdown immediate command:

SQL> shutdown immediate

usually shutdown immediate command will work mostly, but some times when it can hang and fail to shutdown the database. In these cases, the shutdown abort command is named for.

Shutdown Abort:
The shutdown abort command is just about a guaranteed way to get your database to shutdown. It’s a “hard crash” of the database, and this will end in a extended time to start out the database copy .  you aren't really hurting the database using the shutdown abort command, and through your DBA years you'll find quite a couple of occasions to use the shutdown abort command.

A shutdown abort are often your first shutdown method of choice, since there could also be times once you must force the database down. below is the syntax for using the shutdown abort command:

SQL> shutdown  abort