cancel
Showing results for 
Search instead for 
Did you mean: 

Software Component Vector in Modification Adjustment Transport

Matt_Fraser
Active Contributor
0 Kudos

Hello all,

We are in the middle of a support pack project for our SRM system, and I've run into a snag as I prepare to move them into QAS.  We've had this system for many years, and when DEV was originally installed in 2000 it was as a B2B 2.0a system.  It was upgraded to 2.0b before GoLive, and the QAS and PRD systems were installed directly as 2.0b systems.  The entire landscape has been upgraded several times in the twelve years since, and today it is on release SRM 5.0.

The problem is that the DEV system still shows an installed software component of NDI_ERM (Extended Relationship Management) in release 20A.  Obviously that is actually long gone, but it still shows up in SPAM in the Display Package Level function, and under Attribute SAPCOMPONENT in the properties of all transport requests released from this system.  It should have been passively deleted during the first (or subsequent) upgrade long ago, but for whatever reason that didn't happen.  This software component never existed in QAS or PRD and does not show up in SPAM in those systems.

This hasn't been an issue in the past, and so I've just ignored it as I always had bigger fish to fry.  I've performed upgrades and support packages for these systems without an issue, but we hadn't done any of these tasks for the past three years.

Until now.

I successfully installed support package stack 28 for SRM 5.0 into DEV a few months ago, and I performed the required modification adjustments in SPAU, creating the usual modification adjustment transport.  Now, however, when I am trying to import the support packs into QAS, I have a problem when defining the queue, at the step for adding the modification adjustment transport.  The transport is marked with a Software Component Vector that includes the defunct ghost NDI_ERM 20A, and NDI_ERM doesn't exist in QAS.  SPAM finds the transport, but marks it with a red light ("Transport does not fit").  Drilling into details shows me that everything matches perfectly except for my ghost.  On that line I get "The software component is not installed," and SPAM will not allow me to add the transport into the queue.

I should point out that I can import regular transports just fine, and I'm pretty sure I could just import the queue without the modification adjustment transport, and then import it manually when SPAM gets to the step about performing the adjustment.  No doubt that would work, and that's almost certainly what I'm going to end up doing.  But it bugs me that I can't fix this.

I have some thoughts about fixes that might work, and I'd like input on whether anyone else has dealt with (and solved) this problem before.

I think that I could probably just delete the line in DEV in table CVERS for NDI_ERM and so have it no longer show up in the attributes of future transports.  That might solve the problem going forward, though it won't fix the mod adjust transport I've already released.  Any thoughts about this?

I was able to get the existing transport to no longer show NDI_ERM in its attributes by deleting the appropriate line in DEV in table E070A.  After doing that the transport looked fine in the STMS queue for QAS when drilling into its properties.  However, this apparently isn't enough for SPAM.  As I had already uploaded the transport in SPAM once, SPAM 'remembers' it and seems to have therefore cached its properties, including the NDI_ERM software component.  I haven't been able to figure out how to get SPAM to 'forget' this transport so I could completely upload it anew and hopefully get new attributes that will then match the correct software component vector for the target system.  Resetting the queue status doesn't do it.

Any thoughts on where (what tables) SPAM stores information about modification adjustment transports, and how to clear that information out?  Any thoughts on the (admittedly drastic) measures I've mentioned above?

Thanks in advance,

--Matt

Accepted Solutions (1)

Accepted Solutions (1)

Matt_Fraser
Active Contributor
0 Kudos

While I never did find a way to clear the attribute cache for 'uploaded' SPAU transports in downstream systems, I did confirm how to eliminate the 'ghost' component from fouling the attributes of future transports.  As it turns out, the component had to be deleted from tables CVERS, CVERS_LAN, and CVERS_REF, and the system needed to be restarted to clear out all the buffered/cached information.  Deleting it from CVERS was enough for it to no longer show up in SPAM and System Status, but SE10 was still adding it to the transport attributes upon release.  I was able to confirm with function module OCS_GET_INSTALLED_COMPS that it was still stuck in a buffer, but not in the underlying tables.  I tried resetting the Generic Key buffer, but that wasn't enough.  I tried /$SYNC, but that wasn't enough (which really surprised me).  A system restart, and double-checking that the information was also up-to-date in SLD and SMSY in Solution Manager, did the trick.  It's possible re-syncing the buffers and re-syncing SLD would have been enough without a system restart, but the restart made sure.

Matt_Fraser
Active Contributor
0 Kudos

And Aniket is right -- this is NOT a recommended practice.  I would not have done this in a production system.  This was a DEV system, no one else was working in it, and I had access to good backups in case things went south.

0 Kudos

Hello All,

we had a similar issue on a NW740 sp4 ERP installation, where we had Personas3 add-on installed earlier, but the pre-release version.

Later, we were encouraged to install the final (bugfixed) version, released in Aug, 2014.

However, the patched version had the same release numbering (3.00), so it was not possible to install the software on the same name and version, as it came from SMP (saint did not show the newly released add-on as an installable component).

After deleting the referred lines with debugging from tables

AVERS,

AVERS_EXT,

CVERS,

CVERS_REF,

CVERS_LAN

still could not install the add-on.
Finally, found another reference in table

PAT03,

it was deleted, then I could install the add-on.

Hope, it helps, best regards,

Zsolt

d028544
Advisor
Advisor
0 Kudos

Hello,

SAP strictly forbids the modification of those tables for specific Add-Ons or even essential software component. As you do not really delete those products from a SAP system. This will only partially remove meta information from a SAP sytem.  After the "reinstallation" the data and many other log files are still exists and may have some really inconvenient side effects in a SAP systems (inconsistent installation, incomplete database table conversion, problems regarding maintenance via notes and support packages, modifications cannot be reverted...) .

Additionaly it will be very difficult or even impossible to resolve upgrade or maintenance issues.

If you have any  issue regarding an installation of a SAP product, you should contact the corresponding SAP support. They will provide you the right solution. 


Currently SAP only provides for a small subset of Add-Ons the deinstallation.

Thanks a lot for your understanding

with kind regards,

   Thorsten Scheyter  (Development support)

0 Kudos

Dear Thorsten,

thanks for giving the alert.

It is definitely the right solution to apply an uninstallation package instead of table manipulation.

To make clear our case: we have a sandbox/proof of concept system where we applied a pre-release addon following SAP advice for download and install, then as we had troubles with the software SAP provided a bugfixed version of the software with the same version number as before and adviced to install the new one. As it is not possible to install the same software with the same version (even if it is different on code level) and an uninstall package was not available SAP adviced to follow this 'unofficial' way of addon 'uninstallation' as described in this SCN track, however, the risk was mentioned, as well.

Best regards,

Zsolt

Answers (1)

Answers (1)

0 Kudos

Hi Matt,

The best thing here is to raise a message with SAP as it is not allowed/supported to modify SAP internal tables. If you modify it manually and you run into further issues, SAP will not support.

Best Regards,

Aniket

Matt_Fraser
Active Contributor
0 Kudos

Yes, that is certainly true, and I would typically agree with that.  However, SRM 5.0 has gone out of mainstream maintenance as of April 1 of this year.  I have been working with my employer and account rep to get extended maintenance, and that is finally happening, but the wheels of bureacracy turn slowly and so we still aren't in support as of this moment.  Meanwhile, I can't wait; I'm on a tight deadline for this project.

So, I ignored my SPAU transport, imported the queue without it, and then imported the transport when SPAM stopped for modification adjustment.  It worked just fine like that, as I knew it would.  This means, however, that when I get to production I will need to do things the same way in order to use a tested method.  So now any fixes that might be suggested will only be relevant for the next round of support packages or upgrade, which means now I can afford to wait for extended support to kick in.

Nevertheless, I'm still curious to know where SPAM is caching the transport information.

Regards,

Matt