BI 7.0 -> EHP1 (BI 7.01) - with installed SEM-BW/FINBASIS

[Former Member]

SolMan SP21

I'm desperately trying to generate a MOPZ task to update a BI 7.00 with installed FINBASIS and SEM-BW to the corresponding packages for EHP1 (including FINBASIS 6.00/SEM-BW 6.00/SAP_BS_FND).

I was told that with SP21 MOPZ should be able to also generate queues for Addons (at least for the major ones to which I consider those two).

A queue is generated for the Netweaver part but not for SEM-BW, SAP_BS_FND and FINBASIS. The SMSY data is correct.

Am I missing something or is this still to be handled manually?

Markus

[sunny_pahuja2]

Hi Markus,

Have you registered your system as ERP in SMSY ?

Check SAP note 1326576 which says that if Netweaver system containing these ERP packages then it should be registered as ERP system in SMSY in order to download EHP packages.

Thanks

Sunny

[markus_doehr2]

Hi Sunny,

> Have you registered your system as ERP in SMSY ?

No - because it's not an ERP system.

> Check SAP note 1326576 which says that if Netweaver system containing these ERP packages then it should be registered as ERP system in SMSY in order to download EHP packages.

Thank you for that note. Haven't seen that before (it's only 5 days old). I understand this, however, differently:

If you operate a Netweaver system that contains at least one
ERP software component (ERECRUIT, SEM-BW, FINBASIS or LSOFE), 
you must not use a stack XML file created for an SAP ERP system. 
Instead, you have to use a stack XML file for SAP NetWeaver systems. 
The EHP4 packages for the ERP software components have to be
added manually in phase IS_SELECT.

So SAPehpi can not deal with one of those packages.

So I have to do two things:

- a MOPZ task for the Netweaver 7.01 upgrade part

- a "manual" task in IS_SELECT and BIND_PATCH to upgrade the rest

So much again for MOPZ helping to "reduce TCO". A much better approach would be to use a simple SAPup and BIND the packages ALL - so customers won't need to do basically twice the same thing, one "automated" and one manual. Sorry MOPZ developers, all I can do is just disapprove, after 21 SPs it should be possible to install EHP1 including the AddOns (as I was told on the phone some time ago).

sigh

Markus

[sunny_pahuja2]

Hi Markus,

>

> So much again for MOPZ helping to "reduce TCO". A much better approach would be to use a simple SAPup and BIND the >packages ALL - so customers won't need to do basically twice the same thing, one "automated" and one manual.

I am not able to understand with above approach. Could you please explain little bit more the add to my knowledge ?

Thanks

Sunny

[markus_doehr2]

My statement was "wishful thinking".

Basically an EHP installation (no matter of what kind) is a system upgrade. There are only two differences between a classical upgrade (such as R/3 4.7 to ERP 6.0 - or BI 3.5 to BI 7.0):

- the tools name is SAPehpi instead of SAPup

- the shadow instance is built by a copy of the main instance and not by a DVD export

Apart from that the whole process is technically identical to a normal classical upgrade.

My criticism points to the fact, that you have to do two things now:

a) you have to create a MOPZ task to get the XML file (for the Netweaver part - SAP_BASIS, SAP_ABA, PI-BASIS etc.)

b) you have to download, uncar and place the Addon-files in /usr/sap/trans manually (for the rest of the packages)

Option b) is done during normal classical upgrades using SAPup, it worked for the last 10+ years. Queue calculation is running neverless, whether SAPehpi is used or not.

So instead of forcing customers to use MOPZ and "workaround" issues and do things twice one either should develop MOPZ so it can handle the upgrades (which is propagated) or make it optional so people can do normal upgrades without MOPZ, XML and all that stuff.

I think it's just a bit antagonistic to either force customers to use MOPZ and then on the other side not (yet) being able to handle upgrades completely but only 80 % of them; I'm running out of arguments towards management to run SolMan and MOPZ and investing time and so money to keep it current. Credibility is already gone almost completely (what MOPZ concerns).

Markus

[sunny_pahuja2]

Hi

> I think it's just a bit antagonistic to either force customers to use MOPZ and then on the other side not (yet) being able to handle >upgrades completely but only 80 % of them; I'm running out of arguments towards management to run SolMan and MOPZ and >investing time and so money to keep it current. Credibility is already gone almost completely (what MOPZ concerns).

>

Its completely true.

Thanks

Sunny