Setup SAProuter Certificate...

Just for grins this past week, SAP decided to perform some maintenance that resulted in invalidating many SAP customers' certificates. Three of my client sites lost connectivity to SAP via SAProuter immediately following this maintenance last week, and all three had valid certificate inside the 1-year period... nevertheless, I got to help brush some people up on how to renew these certificates.

So, here is the procedure for you, and I will go ahead and leave in the parts you will need of you are starting from scratch.

If you are just renewing your certificates, you can ignore the first part:

First, submit a customer message to SAP Support (component XX-SER-NET-OSS-NEW) and ask them to register the hostname and external IP address of your new SAProuter. You will have to get the firewall opened for communication between this IP address and the SAP network. NAT is okay.

After you’ve received a confirmation from SAP that your SAProuter has been registered, you are ready to configure your SAProuter.

In the following scenario, the SAProuter directory is D:\usr\sap\saprouter. The following SAProuter executables can be found in your kernel directory and should be copied over to the SAProuter directory:

niping.exe
ntscmgr.exe
saprouter.exe
SAPROUTTAB (this is the table you will need to setup for permitting/denying traffic)

1. Set 2 System Environment Variables:
a. SECUDIR = D:\usr\sap\saprouter\SNC
b. SNC_LIB = D:\usr\sap\saprouter\SNC\nt-x86_64\sapcrypto.dll

2. Download the SAP Crypto Library and unpack it into D:\usr\sap\saprouter\SNC (see path above)

3. To request the new certificate, go to http://service.sap.com/tcs > Download Area > SAProuter > Certificates > Apply Now. Take note of the Distinguished Name provided in the lower box.

4. To generate a certificate request, run the command
- “sapgenpse get_pse -v -r D:\usr\sap\saprouter\SNC\certreq -p D:\usr\sap\saprouter\SNC\local.pse”
- Enter a 4-digit PIN, or leave blank
- Repeat PIN, or blank
- Enter the Distinguished Name (Provided by SAP in Step 3), i.e. CN=, OU=, OU=SAProuter, O=SAP, C=DE

5. Create a text file D:\usr\sap\saprouter\SNC\srcert and copy the requested certificate into this file. Then run the command:
sapgenpse import_own_cert -c D:\usr\sap\saprouter\SNC\srcert -p D:\usr\sap\saprouter\SNC\local.pse

6. To generate credentials for the user that’s running the SAProuter service, run command:
sapgenpse seclogin -p D:\usr\sap\saprouter\SNC\local.pse -O [Domain\SAPServiceSID] (this will create the file “cred_v2”)

7. Check the configuration by running command:
sapgenpse get_my_name -v -n Issuer

8. Create SAProuter service on Windows with the command:
ntscmgr install SAProuter -b D:\usr\sap\saprouter\saprouter.exe -p "service -r -R D:\usr\sap\saprouter\saprouttab -W 60000 -K ^p:^"

9. Edit the Windows Registry key:
My Computer\ HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ SAProuter\ ImagePath –> Change both ^ to "

10. Start the SAProuter service

11. Enter the required parameters in OSS1 -> Technical Settings

 

Hope this helps...

RSA1: You Can Only Work in Client 001...

For those of you setting up a BI system for the first time, you will likely encounter this error when trying to run transaction RSA1:

"You Can Only Work in Client 001"

This is because although you can have just about as many clients as you like in your BI system, you may only actively use one client for BI. By default, the working client is 001. If you are like most people, however, you would rather use your own numbering scheme for clients.

When you plan on using a client other than 001 for BI, all you need to do is the following:

1. Go to Transaction SE16, and enter table RSADMINA
2. Leave everything blank to show all entries (there should only be 1 entry)
3. Select the check box in front of the first (and only) row and hit the change button (pencil)
4. Change the BWMANDT field entry to the client number you wish to use

This should fix the problem. No shutdown required, just go straight to RSA1 to check if it worked.

Hope this helps...

Setup SSO between Portal and Target System...

Sometimes the SSO configuration between the Portal and an ABAP system can be pretty quirky, so I thought I would post a step-by-step guide here to help anyone out there who is having trouble with this.

1. Export certificate from the Portal (verify.der and verify.pse)
- a. Navigate to 'System Administration' >'System configuration' >'Keystore Administration'
- b. In 'Content' select "SAPLogonTicketKeypar-cert" and select and save both "Download verify.pse file" and "Download verify.der file"

2. Check SAPJSF user in target system
- a. Create if necessary using transaction SU01
- b. User should have two roles: SAP_BC_JSF_COMMUNICATION and SAP_BC_USR_CUA_CLIENT_RFC (if you have CUA in place)
- c. You may have to generate profiles for these roles in the target system (transaction PFCG)

3. Check profile parameters
- a. Open transaction RZ10 in target system
- b. Select the instance profile, choose 'extended maintenance', then 'Change'
- c. Verify "login/create_sso2_ticket" is set to "2" and "login/accept_sso2_ticket" set to "1"
- d. If these parameters are not set, you will need to set them and restart the target system

4. Export certificate from target system
- a. Open transaction STRUSTSSO2 in target system
- b. Double-click on "CN=..." in the "Own Certif." section, this will populate the center section fields with data
- c. Select "Export certificate" in the center section and provide file name and path to save certificate file

5. Import Portal certificate to target system
- a. Open transaction STRUSTSSO2 in target system
- b. Select "Import certificate" in the center section
- c. Browse to the *.der file created in step 1 and press "Enter"
- d. Select the “Add to certificate list” and then “Add to ACL” (most likely the Portal client needs to be 000)

6. Create a JCo RFC provider in the J2EE engine of the Portal system
- a. Logon to J2EE using J2EE Visual Admin tool (/j2ee/admin/go.bat)
- b. navigate to 'Server' >'JCo RFC provider'
- c. On the right side of the screen choose any entry in 'Available RFC destinations' area
- d. Enter information about new destination:
- - i. Program ID: name of the program (you will need it later) - sapj2ee_port, for example
- - ii. Gateway host - FQDN of target system - server.domain.com, for example
- - iii. Gateway service - sapgw00 for example
- e. In the 'Repository' section enter:
- - i. Application server host - FQDN of target system - server.domain.com, for example
- - ii. System number - 00, for example
- - iii. Client - 100, for example
- - iv. Logon language – EN
- - v. User - SAPJSF (from step 2)
- - vi. Password (from step 2)
- f. Press 'Set'

7. Add target system to Security providers list
- a. Open J2EE Visual Admin and navigate to 'Server' >'Services' >'Security Provider'. In components select 'Ticket'. Enter edit mode (button with pencil above)
- b. Select 'Login module' ’EvaluateTicketLoginModule" and press 'Modify'
- c. Ensure that "ume.configuration.active" is set to "true"
- d. Enter following info:
- - i. Name - 'trustedsysN' (there should be a number instead "N", if target system is the first one you implementing SSO with, there should be 'trustedsys1'). Enter , as a value (C11,100 for example)
- - ii. Name - 'trustedissN' (there should be a number instead "N", if target system is the first one you implementing SSO with, there should be 'trustediss1'). Enter CN= as a value (CN=C11 for example)
- - iii. Name - 'trusteddnN' (there should be a number instead "N", if target system is the first one you implementing SSO with, there should be 'trusteddn1'). Enter CN= as a value (CN=C11 for example)
- e. Press 'OK'
- f. Do substeps b,c,d,e in 'evaluate_assertion_ticket' view for "EvaluateAssertionTicketLoginModule" login module

8. Import target system certificate to J2EE of portal system (from step 4)
- a. Open J2EE Administrator and logon to portal instance
- b. Navigate to 'Server" >'Services' >'Key storage'
- c. In 'Ticket keystore' view press 'load' and select certificate of target system (exported in step 3)

9. Restart J2EE instance

10. Create RFC connection in target system
- a. Open transaction SM59 in the target system
- b. Select TCP/IP connections and press 'New'
- c. Enter name for new connection ("RFC_to_portal", for example), enter connection type "T", description, and select Save
- d. In 'Technical settings' choose "Registered server program" and enter application name (from step 6d) in "Program ID" field, provide 'Gateway host' and 'Gateway service' (same as in step 6d), save, and test the connection

Also, if you are running nto trouble testing the connection on the Portal side, the generic "Make sure SSO is setup correctly" error message is not very helpful. For a more detail error, scroll to the last entry in the dev_jrfc.trc file located in the /j2ee/cluster/serverX/ directory

I hope this helps...

JSPM: All selected SDAs and SCAs have already been deployed before...

I am not exactly sure what caused this error, but while trying to apply Java support packages, I came up with the following error in JSPM:

All selected SDAs and SCAs have already been deployed before

This is a problem, because the Java system still shows to be on an older support package level, but a piece of functionality I need to use is dependent on a higher SP level.

The problem is that the SDM is no longer in sync with the Java stack. The solution is to re-synchronize them.

Here is the procedure:

1. Go to the /usr/sap///SDM/program

2. Run StopServer.bat

3. In the command line, execute the following commands:
- On a Microsoft Windows system:
-- sdm jstartup “mode=standalone”
-- sdm systemcomponentstate “mode=activate”
-- sdm jstartup “mode=integrated”

- On a UNIX system:
-- ./sdm.sh jstartup “mode=standalone”
-- ./sdm.sh systemcomponentstate “mode=activate”
-- ./sdm.sh jstartup “mode=integrated”

- On an IBM eServer iSeries system:
-- QSHcd /usr/sap///SDM/program
-- ./sdm.sh jstartup “mode=standalone”
-- ./sdm.sh systemcomponentstate “mode=activate”
-- ./sdm.sh jstartup “mode=integrated”

4. Run StartServer.bat

5. Restart JSPM

Your SDM should now be in sync with the database.

Hope this helps...

Fonts and Adobe Forms in SAP with Adobe Document Services...

Recently we were experiencing a problem with MICR fonts not showing up when creating a check form using Adobe LiveCycle Designer 8.0 on SAP ERP 6.0. In the past our developers have used mostly SAPScript forms when writing check forms, but this particular check form called for Adobe Forms. The wall we ran into was when trying to get the MICR font to show the check number, routing number and account number in the bottom fields on the check.

Here are a few things we discovered while troubleshooting this issue:

- The SAP MICR fonts MICR_C and MICR_E are installed inside the SAP system
for SAPScript support and for viewing characters in the SAP environment.
- The Adobe LiveCycle Designer tool uses fonts installed locally on the
machine the SAPGui is running on, and does not see the fonts installed inside
SAP.
- The Adobe Document Services (ADS) only sees its default fonts and those
added manually in the J2EE directory structure on the server host.
- ADS creates the PDF files from xml data sent from the frontend LiveCycle
Designer, and utilizes its own installed fonts when generating a form in PDF
format.

If you have a need for non-default fonts to show up in your ADS-generates PDF files, you must first make sure that the fonts are installed in Adobe Document Services, specifically in the Font Manager Service (FMS). To do this, you will need to copy the desired font (.ttf file, for example) into the following directory:

/usr/sap//SYS/global/AdobeDocumentServices/FontManagerService/fonts/customer

If the /fonts/customer directories do not exist, create them. If the other folders do not exist, please check your ADS installation. After adding the font you will need to restart the cluster. It is possible for the settings to take effect by just restarting ADS and FMS through Visual Admin, but I prefer to simply restart the J2EE cluster - it's less work, and we BASIS guys have enough to do already.

Also, you will want to install the same fonts onto the frontend machine that will be developing the forms, otherwise the developer will not be able to select the font name from a drop-down list and will have to key it in exactly as it is named on the server. Plus, the developer will not be able to see the font until he has generated the form and created a print preview.

I hope this helps...

Change Table Schema in SQL2005...

Every now and then while running, installing, and copying JAVA AS for SAP on SQL Server you may run into an issue where the wrong schema is set for a set of tables in the database. This is not a problem if you are willing to completely start from scratch and reinstall Java. For most people, however, that would present a significant problem. Changing the schema of these tables is really the best option in this scenario.

In order to change the schema, you need to use the ALTER SCHEMA command in SQL.
The syntax is as follows:

ALTER SCHEMA new_schema TRANSFER old_schema.table_name

This works like a charm if you are trying to change the schema of a single table. However, there are over 300 JAVA tables for SAP, and your fingers can get pretty tired trying to run this command for each and every one individually.

Try this procedure to change the schema of all tables in a particular schema to a new one:

SELECT
'ALTER SCHEMA new_schema TRANSFER old_schema. '+name FROM sys.tables
WHERE schema_id = x

In this simple statement, you will need to insert your values for new_schema and old_schema as well as the schema_id for old_schema. You can find the schema_id by identifying a table in the old_schema and running the following query:

SELECT schema_id from sys.tables WHERE name = table_name

Hope this helps...

0x8000ffff Login failed for user 'DOMAIN\SAPServiceSID'...

While uninstalling/reinstalling an SRM 7.0 test system, I came across this error in the work process trace file after the SAP system failed to start before post-processing of the install. This was fairly common on Windows/SQL Server systems in the Pre-ECC world and I thought maybe a few new guys would not know how to address this. Basically it is a prblem with the Windows user and SQL Server login not matching up correctly or being mapped together just right. Here is the process I follow to correct this problem, if a simple shutdown-restart of Windows does not fix it:

(Please read through all the steps to make sure you know what you are doing before starting)

- First, make sure that the affected SAP system is completely shut down (the error will only stop the dispatcher, but the other processes may still be running) and stop the SAPSID_xx service. You may have to set the service to "disabled" to keep it from starting up again while you go through the rest of the steps.

- Second, go into SQL Server Enterprise Manager (or Management Studio, depending on what version you are running) and delete the database user DOMAIN\SAPServiceSID (under the database [SID] > Security > users).

- Third, delete the SQL Server Login DOMAIN\SAPServiceSID (don't confuse this with the database user which should already be deleted at this point). It is VERY IMPORTANT that you only remove the SQL Server Login AFTER you have deleted the database user, otherwise you will have to go through another process later to synchronize the database user with the SQL Server login.

- Fourth, create the DOMAIN\SAPServiceSID login for SQL Server with the following attributes:

1. Windows Authentication
2. Default Database: SID (your SAP database)
3. Server Roles: 'public' and 'sysadmin'
4. User Mapping: SID as DOMAIN\SAPServiceSID, default schema 'dbo', with database role membership in 'public' and 'db_owner'
5. Status: Grant 'connect' and enable login

- Fifth, start the SAPSID_xx service (you may need to set it back to 'automatic' if you disable it earlier)

- Sixth, start SAP

If you miss a few of the steps here or the SAPSID_xx service starts back up before you are finished with each step, you may get a 'login not associated with trusted SQL Server connection' error. In this case, you will just need to stop/restart the SAPSID_xx service again after completing all steps.

Hope this helps...