Deployment Optimization During XSS Portal Upgrade

[Matt_Fraser]

I'm in the sandbox phase of a portal upgrade project, upgrading from NetWeaver 7.01 to NetWeaver 7.5, with Usage Type EP-CORE for what is basically just a Self-Services portal (the backend is ERP 6.04). As this portal has been around for a while, EP-CORE didn't exist when it was first installed (we've already upgraded once before, from 7.00 to 7.01), only the full EP usage type, so there are a bunch of extra software components installed that we don't use and don't need: Visual Composer, KMC, etc.

My hope was that the Deployment Optimization Option (https://blogs.sap.com/2013/07/24/doo-upgrade-and-optimize-your-sap-portal-system/) would be available to allow us to strip away all the extra junk and end up with a leaner, meaner, more efficient XSS portal. However, when I attempt to setup the upgrade stack in Maintenance Planner, the tool preselects what looks like every software component under the sun and will not allow me to deselect any. Components that I believe are only applicable to BI Java, VC, and KMC -- in other words usage types EP and BI Java -- are in the stack, and I can't get rid of them. Far from stripping out unneeded components, the tool is adding even more.

I've tried running a CISI (Correction of Installed Software Information) process, and it appeared to work, but that obviously didn't impact this much. I realize Boris's old blog only talks about upgrades to NW 7.3 or 7.4, but it's from 2013 and 7.5 wasn't an option yet then. It also talks about this being part of Maintenance Optimizer, not Maintenance Planner, but MP is the successor to MOpz, and MOpz isn't an option for upgrades to 7.5 anyway.

So, what's the deal? In 7.5 are we forced to install all of the full EP software components, regardless of actual usage? Or is there some further correction, perhaps in LMDB, or perhaps in a repeated CISI process, that will influence this? Or am I misunderstanding something somewhere?

Per Maintenance Planner (after CISI), the current software product stack is:

• EHP4 for SAP ERP 6.0 / NW7.01
• -- Portal Content
• -- Portal Content Common
• -- Portal Content Self Services
• -- SAP XSS (Self Services)
• SAP ERP 6.0
• -- SAP XSS (Self Services)
• -- SAP NW - EP Core
• -- SAP NW - Applic. Server Java

The target software product stack is:

• EHP4 for SAP ERP 6.0 / NW7.01
• -- SAP XSS (Self Services) NW7.3
• -- Portal Content Common NW7.3
• -- Portal Content NW7.3
• -- Portal Content Self Serv NW7.3
• SAP ERP 6.0
• -- SAP NW - Applic. Server Java
• -- SAP NW - EP Core
• -- SAP XSS (Self Services)
• SAP NetWeaver 7.5
• -- Application Server Java
• -- EP Core - Application Portal
• -- Enterprise Portal*

* Note on that last one, Enterprise Portal, it's marked as "to be installed." This seems to be the source of the problem, but I cannot find a way to deselect it. Otherwise, this appears to be correct to me. Is there perhaps a dependency from one of the Portal Content components that's driving this?

Any insight or guidance will be much appreciated.

Thanks!
Matt

[Matt_Fraser]

I have tried everything under the sun that I can think of to resolve this, and after more than two weeks, and learning a few things, I'm still right at square one. I cannot get the Maintenance Planner to not preselect the Enterprise Portal usage type.

I used SDM to undeploy all the DCs (SDAs) (and therefore SCs) related to Enterprise Portal, leaving only the ones needed for AS Java, EP Core, and XSS. This didn't help.

I removed the EP usage type from the BC_SL_ACTIVE_PARTS table (it was still showing up there), and confirmed that it no longer showed up in https://<host:port>/utl/UsageTypesInfo. This didn't help.

I noticed (earlier) that Maintenance Planner didn't seem to require installing the full EP usage type and related components if instead of upgrading to NW 7.5 I just updated the support package stack for the existing release (NW 7.01). So, I did that (my portal was a few SPs behind its related backend anyway). That worked fine as far as it goes, and I thought perhaps SUM, in the processing of updating the support stack, would correct any software information that I missed.

However, despite everything seeming to be fully consistent, when I return to Maintenance Planner to once again plan the full NW 7.5 upgrade, it still insists on installing the full Enterprise Portal usage type.

Two weeks wasted. I'm now under an extremely tight deadline to get beyond the sandbox and get this upgrade live in production. In fact, I now have less than a month. So, I'm out of time to try to resolve this (and I've gotten zero responses to my cry for help here), so I suppose I'm going to go ahead and upgrade this portal and install the full suite of unneeded components anyway, because I can't wait any further.

Still, if anyone has an idea on why this might be (or someone who manages this component on the Support Portal sees this and fixes whatever error is going on), perhaps it can be resolved before I get to DEV next week?

One can hope...

[Matt_Fraser]

Update (2-1/2 years later):

There really never was a solution to this question. I was forced to implement the full Enterprise Portal suite, even if we only utilize a fraction of that. Since then, we have also upgraded our backend to EhP8 (it was on EhP4 when I first asked this), and so today our Portal software product stack looks like:

[Former Member]

Hi Matt,

Not sure whether Deployment optimization is fully available to select/deselect components and also the compatibility with releases.

Keeping time constraint in mind, better option would be going with a regular upgrade (for all components) irrespective of usage. It would be quicker and simpler.

Regards,

Harish Karra

[Matt_Fraser]

Yes, that's what I'm doing, but as I'm still only in sandbox at this point, there are a few days before I do this all over again for the DEV-QAS-PRD track (where I will be committed to the decisions I make).

The number of software components involved in a 7.5 portal vs a 7.01 portal has completely exploded, out of control in terms of added complexity.

The bottom line, I think, is that there must be a bug in the logic of the Maintenance Planner itself.