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...

SAP SRM 7.0 Install...

I just went through a few days worth of frustration, and I have found it in my heart to share with you all the secret that I have unlocked so that perhaps you may be spared the same.
For those of you familiar with earlier releases of SRM, the installation option is found on the ERP installation master media. This is no longer the case with SRM 7.0. It is built on Netweaver, yes, but now the install is no longer available on the ERP media. Of course SAP's documentation on this is severely lacking. In fact all it tells you is that you must locate the "installation master DVD or download." What it fails to tell you, however, is which installation master you need to look for.
through trial and error I found that you will need to locate the Netweaver 7 Enhancement Package 1 installation media, which threw me off a bit. Usually, in the SAP world, an Enhancement Package provides for new functionality in an existing system. This is the first time I have seen an enhancement package be the required platform for a new product. Maybe I am not well-rounded enough, or perhaps my clairvoyance needs work. Regardless, if you are planning on installing SRM 7.0, make sure to locate the Netweaver 7.01 installation master for your platform. In my case the media name was BS 7 SR1 Installation Master Windows Server on x64 64bit.

Hope this helps...

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

After installing a new BI system, we ran across this error before starting the BI configuration and creating connections to the ERP systems. We wanted to do all of our work in Client 100 instead of the default client 001. Of course, when you run RSA1 and get the message "You Can Only Work in Client 001" it stops you dead in your tracks.
Fortunately, there is a simple solution to this.
When you first import the BI content, the system decides what client will be your working client, though it never asks you for this input. By default it will go to client 001 if you do not already have another client built.
If you need to work in a client other than 001, you simply have to change an entry in table RSADMINA. Populate the client field (BWMANDT) in the correct row (most systems will only have 1 row in this table) with the client number you want to work from. Problem solved.
Sometimes this problem will manifest itself in the system log with an entry like this:
DIA 001 100 USER RSA1 D0 1 Transaction Canceled BRAIN 009 ( 001 )
The same process fixes this error as well.

Hope this helps...

"J2EE Status Info Unavailable" After a System Copy...

After performing a system copy with SAPINST, we recently encountered a problem where the SAP Management Console would display the message "J2EE Status Info Unavailable" at the end of the dispatcher status. Then under the Java work process folder, the message "No Info Available" would show up. The exact error messages will depend on your kernel version, but you get the point.
After countless hours pulling out my hair and working with SAP support, we finally discovered the issue. Apparently something went wrong with the Java extract from the source system, so settings were not transferred correctly to the extract files, and thus the target system was populated with erroneous information. Unfortunately, everything from my standpoint was showing to be correct and successful with the system copy. I was only able to correct the problem by returning to the source system and running a new System Copy, utilizing the "database specific" option so that SAPINST only ran the Java migration steps. I then went to the source system and re-ran the system copy target steps, and pointed it to the new Java Migration files.
Worked like a charm.

Hope this helps...