Trouble Removing a Custom Package and Add-On from your SAP System...

So I recently came across this issue with a friend and colleague:

A customer requested that we remove a 3rd party SAP add-on they were no longer using from their SAP system. The package was causing unnecessary complexity each time they applied service packs or performed an upgrade. Normally an add-on can just be excluded from the upgrade or update and it will no longer exist in the newly updated system, however this particular package would not cooperate. The original vendor said they would not help with removal because it was not designed to be uninstalled, so the customer asked if we could take care of it.  As a side note, I think it is pretty bad form for a 3rd party software developer to design and sell an SAP add-on product that cannot be removed or not provide a method to do so.

After the usual process of identifying and deleting the objects within the package, we continued to find remnants of the product in the system.  To make a very long story short, after much head-scratching and research, we were finally able to get the add-on removed.  Here are the things we had to do in order to get the more difficult pieces out of the system:

First off, after deletion go to SE80 and display the package. Right-click the package, choose Others>Rebuild Object List in the context menu. Here you can check whether there are other objects which are not yet deleted. If there are no objects shown in the package, then release the change request. Then try to delete the package. (note: the entry in table TADIR will not be deleted until you release the change request)

Secondly, you may run into some orphaned object entries. To find objects that still have object directory entries, you can search the TADIR table for your package (DEVCLASS) and see what entries are there.  If there are objects listed that truly do not exist in the system, the entries can be removed from this table. 

CAUTION: only remove TADIR entries if you are absolutely sure they do not exist, otherwise you will create orphaned objects in the system.

To find orphaned objects in your system, run transaction STDR. Here you can also clean up the object directory manually or en masse.

After all of this, you may also run into some OTR entries that still prevent you from deleting the package. The way to get rid of these is with report BTFR_DELETE_HEADERS.

Finally, the package contents were all gone and we were able to successfully remove it from the system.

Hope this helps...

Stopping a Dialog Instance on a Running System...

Sometimes you will find yourself in the situation that you need to stop an SAP Dialog Instance while the Central Instance and Message Server are still running.  This can be tricky, but you can avoid any disruptions in service or failed processes if you follow these easy steps:

1. Run transaction SMMS, choose the Dialog Instance you need to stop, and select Goto > Expert Functions > Servers > Deactivate.  This will put the instance in passive mode, which prevents any new processes from being started on that instance. This can also be done from transaction SM51 by choosing the instance and selecting Goto > Server Name > Administration > Deactivate.
2. SM66 will now no longer show any active processes on that instance, however this is because your session cannot get to that instance while it is deactivated.  You will need to watch the ABAP Work Process Table from the SAP MMC Management Console. When all the processes are idle, then it is safe to stop the instance.
3. Be sure to ONLY stop the dialog instance or you will kill active processes.

Keep in mind if you only have a single Dialog Instance, you will be effectively halting all system access, so it is best to only do this if you have multiple Dialog Instances in you landscape and logon groups.

You will also want to keep in mind that any user sessions already on that instance will still be attached to that instance, so when you stop the instance their sessions will be lost.  You will first want to have users connected to that instance log out and back in so that they connect to one of the Active instances.

When you start the instance back up, it should automatically go back into Active mode, so you will just need to verify that in SMMS or SM51.

Hope this helps...

Enable or Disable Transparent Data Encryption (TDE)...

Transparent Data Encryption (TDE) is one of the options to protect your data available wih SQL2008. This encrypts your database, data files, transaction log, and the backup files created for your database.  Keep in mind, however, that this has been known to cause a 20-25% increase in processor load and a significant performance hit.  But if your number 1 priority is encrypting your data, this is one option.

Enabling TDE Encryption

The following SQL commands will get TDE setup in your SQL2008 database. You must have a certificate and private key already generated for this.  Like many sites, you can use the same certificate and private key for all of your SQL2008 Databases.

--- SET ENCRYPTION

USE master;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password'

GO

CREATE CERTIFICATE tdeCert

    FROM FILE = 'path to certificate file'

    WITH PRIVATE KEY (FILE = 'path to private key file',

    DECRYPTION BY PASSWORD = 'password');

GO

USE DBNAME

CREATE DATABASE ENCRYPTION KEY

WITH ALGORITHM = AES_128

ENCRYPTION BY SERVER CERTIFICATE tdeCert;

GO

USE master;

ALTER DATABASE DBNAME

SET ENCRYPTION ON;

GO

After this command, you can check the status of the encryption of the database with the below query.

--- CHECK ENCRYPTION STATUS

USE master

SELECT database_id, encryption_state, percent_complete

FROM sys.dm_database_encryption_keys;

GO

Now you’re all set.

Disabling TDE Encryption

The following process will get TDE removed from your database, after you have determined the performance hit is too much, or the novelty of having an encrypted database has worn off.

Removing TDE is basically the reverse of enabling it, however you will need to wait between steps.

--- REMOVE ENCRYPTION

USE master;

ALTER DATABASE DBNAME

SET ENCRYPTION OFF;

GO

This will make the database start the decryption process. Use the query below to check the status of the decryption process.

--- CHECK ENCRYPTION STATUS

USE master

SELECT database_id, encryption_state, percent_complete

FROM sys.dm_database_encryption_keys;

GO

You may need to truncate the transaction log, or shrink the log file, if the encryption state stays at 2 with percentage 0 for a long period of time. Then stop/restart the SQL Server instance. When your server is back up re-run the above query to see the complete decryption status. This second time will run much faster.

Once the process completes and the database_id you are decrypting is no longer encrypted (will show encryption state 1 when complete), you can go on to the encryption key removal.

--- REMOVE THE ENCRYPTION KEY

Use DBNAME

DROP DATABASE ENCRYPTION KEY

GO

Now simply remove the master key.

--- REMOVE THE CERTIFICATE AND MASTER KEY

USE master

DROP CERTIFICATE tdeCert

DROP MASTER KEY

GO

The process of decrypting the database should now be complete.

Hope this helps...

Using Message Server Logon/Load Balancing with SICF Services, Including NWBC…

I know a lot of you have run into this issue in the past: You are using BSP’s or other services, or NetWeaver Business Client, and you have outgrown the single application server landscape.  The simple solution is to implement additional application servers, right? Well yes, but if you were not using logon balancing before, it may be a bit tricky to figure out what all needs to be done in order to utilize these new application servers from the end user standpoint.

Using the Message Server’s built-in logon balancing function, you can get this done in a matter of minutes.

Pre-requisites:

-        - You have already installed the new application servers and connected them to the Central Instance.

-        - Message server ports must be configured for access. 

-        - SNC must already be setup in order to utilize HTTPS load balancing

First, you will need to go into transaction SMLG and create at least one logon group and assign an application server to it. I like to have a few of these so that when a client’s system grows it is simple to spread out the load. You will want to name it something that you will be able to easily identify, like say NWBC. Once this is created, then create another one with the exact same name (case sensitive) and assign another application server to it.  In the Properties tab for the logon group you can set it to use the balancing logic Round Robin, Best Performance, Probability, or Weighted Round Robin.  Once you have all the instances you want assigned to the logon group, you are ready to configure the service to use it.

Next, go to transaction SICF and double click the service you wish to take advantage of load balancing. In the Service Data tab, select your logon group from the Load Balancing dropdown field, and save. You can double check that logon balancing is activated for this service in transaction SMMS. If you want to assign all activated services to the same logon group, you can assign the group to the top level default_host service, but I would not recommend it unless you are sure you will always use this logon group for all services.

Now all you need to do is make sure end users are logging into these services through the message server port rather than a direct link. The default message server port is 8100 (or 44400 for HTTPS), so your URL link to be used should be http(s)://message_server:8100/service_path. You will also want to make sure that the URL in the users’ NWBC desktop client is changed to point to the message server rather than a direct link to the application server.

Hope this helps…

Ignore Password Expiration when authenticating with SSO

One of the most annoying things about having multiple systems within an SAP environment is the fact that people have to remember passwords for every component system within the landscape.

SSO resolves this problem, for the most part, but there's still that annoying little fact that initial passwords must be changed at first login, and passwords may be set to expire every so often.

Well, you're options for avoiding these problems are as follows:

1. Deactivate passwords

2. Have the component systems ignore expired passwords when utilizing SSO

Option 1 is great, if your users will never need to enter a userID and password. This puts the entire authentication burden on some other application (like Active Directory).  But this is not necessarily the right solution for all clients.

Option 2 is what I choose, primarily.  In order to do this, you need to set profile parameters in all ABAP and Java systems in your landscape.

For the ABAP systems set the following profile parameter:

login/password_change_for_SSO

This profile parameter determines precisely how the system will react in the situation in which a user accesses the system through SSO and their password is expired (or initial).  Here are the values:

0 = Ignore password change request, and allow access

1 = Present a pop-up window with options 2 and 3 below

2 = Require the password be changed, including old password and new password

3 = Deactivate the password

This is a dynamically switchable parameter and can be turned on in RZ11 without the need for a restart, though you will have to modify the profile to make the change permanent.

For the Java systems, open Visual Administrator, and under the UME Provider service, set the following parameter to False:

               ume.logon.force_password_change_on_sso

This is not dynamically switchable and will require the cluster to be restarted.

Now both your ABAP and Java systems will ignore expired passwords.

Hope this helps…

NetWeaver Portal not behaving with Internet Explorer SSL and TLS settings…

NetWeaver Portal not behaving with Internet Explorer SSL and TLS settings…

Recently on a client site we ran into issues with the internal users being unable to connect to the portal while using the same SSL (3.0) and TLS (1.0, 1.1, or 1.2) settings necessary for other SAP or 3^rd party applications.  This may be related to Microsoft security updates KB2585542 and KB2618444, though the client does not have record of applying these.

This is specific to Internet Explorer 8 or higher.

The errors you may receive include “connection timed out” and “page cannot be displayed” though others have seen spurious other generic error messages.

There are two possible solutions:

1. Update your AS Java to the latest Support Package.  Unfortunately this was not an option at this client site, so we had to go with the work-around below.

2. To implement the workaround change the SSL server configuration as follows:
- Open Visual Administrator and log in
- Select Dispatcher -> Services -> SSL Provider
- Select the line with port number corresponding to your web server (default 5xx01)
- remove all cipher suites except the following:
  SSL_RSA_WITH_RC4_128_SHA

Keep in mind, if you implement this work-around, remember to add the appropriate TLS cipher suites back when you update AS Java.

Hope this helps…

SYSTEM_NOT_CONFIGURED_AS_XMB...

Typically when you get this message in SAP PI, it means that the system you are trying to send a message to is not setup to receive the message.  The way to correct this error is to go on the receiver system an set the Integration Engine Configuration in transaction SXMB_ADM.
Go to Edit >> Change Global Configuration Data.

Role of Business System:  Application System
Corresponding Integ. Server:  dest://[Integration Server RFC destination]

Save and retry.

Keep in mind that if you are doing this with messages from SRM to SUS (and SUS is a separate client on your SRM system) you will need to configure this in both clients.

Hope this helps...

SUS contact person password change is not synchronized to SRM…

The scenario is this: A temporary SUS user that was previously created through the self-registration process logs in and creates his permanent SUS user ID. At that point, the SUS user is created and it is synchronized to SRM, with an identical initial password.  When the SUS user logs in for the first time, he is prompted to change his password.  This is fine, and operates as expected. However, once this same user attempts RFx functionality (or any other function that makes a call to the SRM backend) the user is prompted again to change his password.  The confusion caused here is the password that needs to be changed is the original initial password from the SUS user creation, not the current SUS user password. From the user standpoint, they do not know this because it is not intuitive that they are passing from one system to another.

SAP has come out and said in note 1802240 that the password is not synchronized by design.  I will not venture to guess as to the reasoning behind this, however in researching ways to fix this from a functional standpoint for my customer I came across a very simple solution.

I was looking at our options, and came up with these:

1.      We could change the creation logic with a Z program to force the password to be deactivated in the SRM system when the user is created.

2.      We could change the synchronization function modules with a Z program that includes the logic to force the password change to be included with other user details when the synchronization occurs.

3.      We could just do nothing and provide detailed instructions for the customers on how to work with this design defect.

Each of these potential solutions also brought with them their own drawbacks, especially option 3, but each are valid solutions.  However, I ran across am option 4 that never occurred to me before.  I came across the following profile parameter

login/password_change_for_SSO

This profile parameter determines precisely how the system will react in the situation in which a user accesses the system through SSO and their password is expired (or initial).  Here are the values:

0 = Ignore password change request, and allow access

1 = Present a pop-up window with options 2 and 3 below

2 = Require the password be changed, including old password and new password

3 = Deactivate the password

So, the solution that was best for this customer was to choose option 0, which will allow the user access through SSO and not prompt for the password to be changed.  The customer loved the solution, and I will certainly add it to my bag of tricks.

Hope this helps…

Connecting two BW systems to the same ECC system...

Connecting two BW systems to the same ECC system (or any other SAP system) is (normally) very easily accomplished. You simply create a source system connection to the ECC system (or other SAP system) in RSA1 on each BW system.  Simple.
However, where this becomes difficult is if one of your BW systems was built as a system copy of the other BW system. Let's say you want your Training BW system to point to the same ECC system as the QA training system, and your Training system is a copy of your QA system.
When you try to restore the Source System connection in RSA1, the process will prompt you to delete the existing connection on the Source System side.  That works fine for the BW system that you are setting up at that time, however it severs the connection to the existing BW system.  I could go into great detail on why this occurs, but I am sure most of you are looking for a solution and want it quick.
So, here's the solution (all steps are performed on the new BW system unless noted otherwise):

1. Execute SM59 and delete the RFC connection to the Source ECC system (or other SAP system).
2. Execute RSA1 and delete the Source System definition
3. Execute RSA1 and create a new Source System definition, utilizing a different USERID for the RFC than what was previously used, since that user ID will already exist in the Source System and is tied to the existing BW connection. Keep in mind you will have to have the ECC client opened for changes in order to activate the connection.

Now both the original BW system and the newly copied BW system can connect to the same ECC system.

Hope this helps...

ConfigTool Will Not Start: System Cannot Find the Specified Path...

I ran into an issue recently that has me a little puzzled. Although I have the solution, I have yet to determine the root cause.  This morning I had a problem restarting an SAP Java system, and the errors contained in the logs seemed to be pointing to missing elements in the binary files. This would cause the Java Server process to fail when it attempted to synchronize the binaries (one of the first steps in starting the system).
So I tried to open the ConfigTool, and it immediately came back with the error:

System cannot find the specified path

So being the good little Basis boy I am, I opened up the ConfigTool.bat file to see what path it was looking for. Lo and behold, the batch file was simply looking for the contents of Java_Home (environment variable).
So I opened up the location only to discover that someone, or something, has gutted the Java folder. All that was left was the JRE subfolder.
Then I remembered this has happened before. About 7 or 8 months ago the same thing had happened.

The fix is quite simple, just reinstall Java in the same path.  The system will come back up just fine.

Now I just need to figure out who, or what, has been deleting OS-level files. That is not good.

Hope this helps...

Setting Up NetWeaver Portal for Simple External Access...

When you want to setup your portal to be accessed externally through a Web Dispatcher, you need to consider several things.  Simply opening up the correct ports and pointing the Web Dispatcher to the Portal and backend systems is not going to be sufficient. Every link within the portal that you click on, and every page redirect and pop-up will need to establish communication with a system that resides within your network that is not externally visible on it's own.  When the portal attempts to connect you, it will use an internal address which will only produce a "Page cannot be displayed" error in the end user's browser, or a "Portal domain differs from Application domain" error when trying to utilize single sign-on.

In an environment where the Web Dispatcher resides in a DMZ and all portal/application servers are internal these are some of the steps I take:

1. Validate that all necessary ports are open: The port coming into the Web Dispatcher from the outside, the ports from the Web Dispatcher to the portal and application servers, and the ports between systems that will need to communicate.

2. Validate internally that all connections (SSO, ITS, and WAS at least) are working from the portal. I use only HTTPS, even internally. This makes sure that SNC is configured correctly and certificates are in place.

3. Validate Web Dispatcher certificate is valid and present. This is simple: just connect to the Web Dispatcher with a browser and look for the secure icon or certificate error.

4. After you know that all communication between the portal and the application servers are working, you need to re-point the portal's system definitions to the outside address.  If the external URL for your Web Dispatcher is https://portal.mycompany.com, then that is what you need to point the system definitions to within the portal.  This will likely cause your connection tests to fail, however the actual scenario will work. Instead of your portal links trying to reach internal addresses externally, it will route that traffic through the Web Dispatcher as long as you have the correct systems defined within the WD profile.

5. Change all external facing URLs configured in your backend systems to also use the external link (SUS emails, approval links, etc.).  Anything that is designed to be seen or clicked on externally needs to point to an address that is accessible from outside your firewall.

Following these steps should get you well on your way to getting your portal accessible from the outside world.

Hope this helps...

NetWeaver Business Client (NWBC) Does Not Save Favorites...

Okay, so every now and then I will come across something very odd that doesn't seem to have a documented solution out there. Well, here is one of those times.  Some users were unable to save their favorites in NetWeaver Business Client: they could create a favorite, but as soon as they closed the interface it would be gone.  Long story short, NWBC saves your favorites in a file named NWBC.fav.  This file is stored in the \Application Data\SAP\NWBC directory.  Depending on your company's group policies, the Application Data directory may exist on your local machine or on a network share. All you need to do is create the NWBC directory in the correct location, create a favorite, and the interface should create the NWBC.fav file.

Hope this helps...

User TMSADM Keeps Getting Locked Out...

Don't you hate it when you can't refresh your STMS queues without having to enter a username and password for every system, only to inevitably lock your accounts in each system and the TMSADM user as well?

I know I hate it... or at least I did until I found a simple solution:

This actually comes from SAP, only it is not as easy for somebody to find, even if they know where to look.

Most likely you have complex password requirements in your landscape, and the default TMSADM passwords do not meet those requirements.

Just follow this procedure:

The password can be changed only from the domain controller by the Transport Management System (TMS) administrator.
Start the report TMS_UPDATE_PWD_OF_TMSADM in client 000.
On the selection screen, the report offers three different options for changing the TMSADM password:

• Enter your own password.

• Set the standard password

• Reset the password to the original TMSADM standard password (used since Release 3.1I)

           This is the return path if unexpected problems occur when you change the password. This works only if all of the systems still accept the simple password. Otherwise, you must find a suitable password.

The report offers the connection test across all systems and a log display of the changes as additional functions.

After you select one of the password options, you can choose "Execute". The system then requests logons in client 000 of every system of the TMS domain.
The connections to all systems of the landscape are then set up for the entire run of the report.

The report executes three phases:

• Creating test users and test destinations in all systems

• Checking the test users and test destinations

• Setting the required entries in the table TMSCROUTE, changing the TMSADM user accounts and the TMSADM destinations

Errors in phases 1 and 2 cause the report to terminate.
If the first two phases are successful, the system continues with the third phase in all systems without taking the errors into account. The system then displays a log for all actions, which you can display again at any time.

Now your troubles should be gone.

Hope this helps...

How to enable SQL Transparent Data Encryption on the Target System of a System Copy…

If you have an SAP system that you are planning to make a copy of and you have TDE enabled on it, you will run into a problem when trying to copy the database.  This is because the source system is protected from the exact thing you are trying to do.

In order to make this work, you will simply need to setup your Target System to use the same encryption certificate and key as the source. This should not be a problem, since you should have access to all the necessary information and files.

The TDE keys should be found in the SQL Server directory structure on the source system. For example, it may be stored here:

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

For simplicity in scripting, it may be wise to copy the files to a different directory temporarily. I had to copy them to a local drive for the query to work correctly.

You will need the following files: tdeCert.cer and tdeCert.pvk

You should also use the same encryption password used to originally set TDE in the source system.

Make absolutely sure you have the tdeCert.cer and tdeCert.pvk files and they are located as stated in the script before running the script. Otherwise encryption will be set without the necessary information for the copy to work, and you will have to remove the encryption and start again.

Script:

USE master;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[password that you set]'

GO

CREATE CERTIFICATE tdeCert

    FROM FILE = 'C:\tdeCert.cer'

    WITH PRIVATE KEY (FILE = 'C:\tdeCert.pvk',

    DECRYPTION BY PASSWORD = '[password that you set]');

GO

For another example of how to do this see http://sql-articles.com/blogs/how-to-copy-move-a-database-that-is-encrypted-with-tde/

Hope this helps...

PPS can only be activated in the extended classic scenario

Hello all,
Usually I have the functional consultants activate the business functions, because the are usually prerequisites from the functional side, and the majority of these are not reversible.  However, this past week I was tasked with turning on PPS in an SRM system. Okay, there were 5 switches the team wanted turned on, so I figured that was easy enough. Unfortunately I kept hitting an error while trying to activate a PPS function:

"PPS can only be activated in the extended classic scenario..."

So, naturally I started looking for the Business Function that matched that description... except there wasn't one. I did look up the prerequisites, and from a business function standpoint they were already met.  After a quick Google search I came up with the solution (which was surprising, considering I misspelled my primary search term).

In order to fix this, one must dive into SPRO and activate the following:

Supplier Relationship Management → SRM Server → Cross-Application Basic Settings → Activate Extended Classic Scenario

Just set that, and you can activate PPS to your heart's desire. Keep in mind this setting is client dependent and must be set in EVERY SRM client.

Hope this helps...

Joey

Various Connection Errors with SAP Portal, SRM, PI, UWL, etc...

Hello readers,
I know it has been a while since I posted anything here. I have been busy.  Just thought I would pop by and enter another little note.

On a client site I was having some sporadic connection issues between the portal, SRM, SUS, ECC, PI, etc.  All configuration and system settings seemed to be correct, however after several minutes of moderate use (or several hours of light use) things would stop working.  The UWL would begin throwing "credential" issues, the SSO connection tests would begin to give error, and iViews stopped providing information from the backend.
After some digging I found the following line in the Java logs in multiple locations:

"Max number of 100 conversations exceeded..."

Then it hit me.

So I went to the server and made sure to check for the CPIC_MAX_CONV system environment variable in windows.  Sure enough, it was not set. Thus the system was stopping CPIC connections at 100 (the default).

After setting CPIC_MAX_CONV to 2000, and restarting the SAP system all these sporadic errors went away.

Just an FYI, this is something that should be set at initial install, and as observed it can cause many strange communication errors if it is not set.

Hope this helps...

Joey

Running but Dialog Queue Info Unavailable, J2EE Status Info Unavailable...

We have all seen this after upgrading a kernel or after an initial installation of an SAP system, but I thought I would expound a little upon why it happens.  When creating the service used to start SAP in a windows environment, you use an executable called sapstartsrv.exe.  This file is found in Kernel Part I (database independent), but it is also found in the SAP Host Agent executables as well as in the Disp+Work Package.
On the Kernel download page in the SAP Service Marketplace, you will find multiple versions of each of these. However, the most recent version of each may be different.  It is critical that you make sure your disp+work.exe and sapstartsrv.exe are the same version and patch level. If they are different, you can run into issues from not seeing dialog process information to not being able to start the SAP system at all.
1. Right-Click on the executable
2. Choose Properties
3. Look at the Details tab
4. The Product Version for disp+work.exe and sapstartsrv.exe must be identical

Also, you will want to look at the details of your service definition to make sure you are using the sapstartsrv.exe from the correct kernel directory. Some systems have the service running from a copy of the executable in the Windows\System32 directory, which is not necessarily updated when the kernel is updated. To remedy this, follow this process:
1. Make sure your SAP system is in a shutdown state
2. Double-click on sapstartsrv.exe in your active kernel directory "usr\sap\SID\INSTANCE\exe"
3. Enter all the required information
4. Repeat for any other systems/instances on the server

Hope this helps...

Authentication failed. User is already authenticated as a different user...

For those of you who have recently gone through a system copy of your SAP Java system, or have tried to update your SAPLogonTicketKeypair certificates in Visual Administrator, you may have run into this issue.  You change the certs to match the dates you need or you change the system name to generate a new cert, but now when you try to login to the portal you get this message:

Authentication failed. User is already authenticated as a different user

Fear not, this is a fairly simple problem.  When you generated the new certs, odds are you chose the default encryption RSA, instead of DSA.  Go back to Visual Administrator and recreate the certs with DSA and you should be fine.  You won't even need to stop and restart the cluster.


Hope this helps...

JSPM Error in upgrading UWLJWF to 7.01.7 or above...

We actually ran into this problem this week. When upgrading one of our portal servers, we got a strange error:


sap.com/UWLJWF: Deployment of archive ... UWLJWF07_0-10005903.SCA has been terminated. Aborted: software component 'UWLJWF'/'sap.com'/'SAP AG'/'1000.7.01.7.0.20100612231021''/'5': Failed deployment of SDAs: development component 'com.sap.netweaver.bc.wf.db'/'sap.com'/'SAP AG'/'7.0107.20100604135629.0000'/'5' : aborted. Please, look at error logs above for more information! 


So, being inclined to troubleshoot first and ask questions later, I tried it again.  It still failed.  So I deleted the SCA and downloaded it again from the marketplace, and gave it another shot.  It failed yet again.  The next thing I thought was that perhaps there was a problem with JSPM itself, so I updated a single package (from the top, I forget which one...) and it worked just fine. Next I tried a group of three or four packages. Again, it worked fine.  Okay, so at this point I was pretty sure the problem was with UWLJWF specifically.


After some digging, I cam across this note from SAP (SAP Note 1442501).  Apparently there is a problem with the KMC_WF_SUBSTITUTE table prior to 7.01.7 which causes the update to fail, if there are any entries in it.  Fortunately our Sandbox system was a copy of our Production system, and we got to see this problem early on, otherwise we probably would not see it until we tried to go live with SP7.


The way to fix this is specified in the above note, but might I suggest another approach.


The note suggests that you export the table contents, delete the table, continue the update process, then re-import the table contents.  This is the correct procedure, but I prefer to leave little to chance.  I do the same thing, except instead of continuing the update process for the entire stack, I simply do it for the UWLJWF component alone.  


Here is my process:

1. Open up the KMC_WF_SUBSTITUTE table in SQL Management Studio, highlight and copy all the rows, and paste into notepad
2. Drop the KMC_WF_SUBSTITUTE
3. Update just the UWLJWF component
4. Open up the KMC_WF_SUBSTITUTE table in SQL Management Studio (it will be there again, because the update replaces it), and simply paste the data back in. It should still be in your clipboard from the previous copy.
5. Continue the update for all the other components.

Doing it this way, you don't have to worry about writing any export/import scripts (I only use notepad in case I wipe my clipboard), you don't have to add another step to the end of your update process (did I or didn't I put those table entries in?) and it is fairly quick and painless.


I hope this helps...

EHPI Error: Phase XPRAS_UPG, DDIC_TYPE_INCONSISTENCY...

This is a fairly common error in the EHPI process. Sometimes a table will have an include field that references an invalid field from another table. That field may have one day existed and for some reason no longer does.  In order to move past this error in the phase XPRAS_UPG, you have to purge the offending field.

First, make sure to correctly identify the field. There will be detailed information about the table/field in the Short Dump in ST22. Make sure you are thorough, because you do not want to alter the wrong table. For example, the most recent one I ran into was the NETPR field in table EK08RZ.  The error in the short dump referenced table DRSEG.  The short dump references a report you can run to identify the problem field, but I won't reference here because I REALLY want you to read the short dump.

Here are the steps to correct the problem:

1. Unlock the Shadow System to allow a user to login:

 From the command line, run:
\usr\sap\<SID>\<inst>\exe\TP UNLOCKSYS <SID> PF=<profile path>

2. Set the system to allow for changes:

SE06 -> System Change Options, set the system to modifiable for both Software Components and Namespaces

SCC4, Allow changes to both client dependent and repository objects

3. Remove the field

SE11, modify the table and remove the invalid field

4. Close the system in SCC4 and set the system to Not Modifiable in SE06

5. Lock the Shadow System:
\usr\sap\<SID>\<inst>\exe\TP LOCKSYS <SID> PF=<profile path>

Resume the step in EHPI.

You may run into multiple invalid fields, so be patient with this process.

Hope this helps...