SAP_ESS 633 import fails

[Former Member]

Hi all.

I'm trying to create a TRACK into NWDI to add SAP_ESS SC and the Development import fails. We are on Portal 7.30 and SAP_ESS 633.

I've created the TRACK using the wizard (through NWA) and manually, both attempts failed. I've added SAP_ESS 633 to TRACK and imported the SCA for the SC dependencies defined in SLD and still fails. Then I've added the remaining dependencies from SAP note # 1457908, imported the SCAs and still fails.

When the import fails it restart the server, puts the build space on PRIVILEGED input mode and add INIT_COMPARTMENT request to CBS.

Reading the log for the failed activation request it shows errors:

"... does not exist [public-part: def] AS Build Plugin Dependency

[validity: USED COMPONENT OR PUBLIC PART IS UNKNOWN OR UNDEFINED]: Invalidated"

for missing dependencies:

'sap.com/tc/bi/bp/webDynpro', 'sap.com/com.sap.aii.proxy.framework', 'sap.com/com.sap.mw.jco' and others.

It seems to me that SAP_ESS 633 its still using old version dependencies.

Seeing the build space information through CBS Web GUI shows 321 total DCs and 10 broken DCs.

More information:

Portal: 7.30 SP09

SC added to TRACK: SAP_ESS 633 SP0

Dependencies:

ECM-CORE         7.30 SP09

ENGFACADE      7.30 SP09

ENGINEAPI        7.30 SP09

EP_BUILDT         7.30 SP09

ESCONF_BUILDT             7.30 SP09

FRAMEWORK    7.30 SP09

J2EE-FRMW       7.30 SP09

MOIN_BUILDT  7.30 SP09

SAPPCUI_GP     7.30 SP09

SAP_BUILDT      7.30 SP09

SERVERCORE     7.30 SP09

WD-RUNTIME   7.30 SP09

WD-RUNTIME-EXT         7.30 SP09

Am I missing some SC dependency?

Have somebody an idea what could be happening?

Regards,

Gregory.

[ErvinSzolke]

Hi Gregory,

according to the SLD content of my test server the SAP_ESS 633 has the following build time dependencies

  WEB DYNPRO RUNTIME EXT 7.30

  WEB DYNPRO RUNTIME 7.30

  DI BUILD TOOL 7.30

  J2EE ENGINE FRAMEWORK 7.30

  EP BUILD TOOL 7.30

  J2EE ENGINE SERVERCORE 7.30

  ENGINEAPI 7.30

  SAP PCUI_GP 633

  J2EE ENGINE FACADE 7.30

  JAVA FRAMEWORK OFFLINE 7.30

As I can see you have also mentioned these SC dependencies, and I assume you have imported them into dev and cons spaces.

However the error message

"... does not exist [public-part: def] AS Build Plugin Dependency

[validity: USED COMPONENT OR PUBLIC PART IS UNKNOWN OR UNDEFINED]: Invalidated"

usually means that there is a missing SC dependency, it even points to DCs

''sap.com/tc/bi/bp/webDynpro', 'sap.com/com.sap.aii.proxy.framework', 'sap.com/com.sap.mw.jco'

which are in SC SAP_BUILDT.

Regarding the 321 total DCs and 10 broken, please click on the SC that contains broken DCs (in CBS webui) and then attempt to locate the DC that is broken by itself (has compile errors) and double check the request and/or build log of that one.

See also the guide that can help in this:

Understanding Broken DCs and Dirty DCs
http://scn.sap.com/docs/DOC-1177

The TSG might also come in handy:

https://wiki.sdn.sap.com/wiki/display/TechTSG/%28JSTTSG%29Main+Page

(see here CBS reports broken DCs)

Best Regards,

Ervin

[Former Member]

Hi Ervin,

Thanks for your answer.

Yes, I've imported the SCs listed in SLD as build dependencies for SAP_ESS 633. Additionally I've imported SCs for remaining dependencies from SAP note # 1457908 (only for WDJ development) but the error persists.

I've checked the 10 broken DCs and them belongs to COMP_BUILDT (6 broken DCs), ESCONF_BUILDT (1 broken DC) and MOIN_BUIDT (3 broken DCs) the missing dependencies are listed below:

'sap.com/tc/bi/javatech'

'sap.com/tc/moin/bi/moinext'

'sap.com/tc/moin/bi/moinlibs'

'sap.com/tc/bi/wstech'

'sap.com/tc/bi/bp/ejbmodule'

'sap.com/bie/sca/scdl/gen/util'

'sap.com/tc/moin/bi/bp/mmbuildplugin'

I'm trying to find out what other SC I have to import to solve this and see if this is the reason why import is failing.

Regards,

Gregory.

[ErvinSzolke]

Hi,

try to find the DC(s) of the 10 broken DCs which have compile state errors, and then check the build log of that DC, that will tell you the reason for the brokenness.

Regards,

Ervin

[Former Member]

Hi Erving

I've found 0 DCs for SCs that I've imported before (i.e. FRAMEWORK) and the import log was OK. I've reimported those SC then reimported the SC containing broken DCs and solve the "broken DC" problem, obtaining 1102 total DCs into the build-space.

After this I've reimported SAP_ESS 633 SC and activation request still fails, restarting the server, setting the build space on PRIVILEGED input mode and adding an INIT_COMPARTMENT request to CBS.

Now the difference is there aren't dependencies errors into activation log, messages listed below:

• Resource "/SCs/sap.com/SAP_ESS/_comp/TopLevelDCs/sap.com ess tw pid cfg.dcref" is not relevant for DC build and will be ignored. Reason: Invalid DC URL '/SCs/sap.com/SAP_ESS/_comp/TopLevelDCs/sap.com ess tw pid cfg.dcref'. URL does not point to DCs root directory. (for all components)
• 528 components to be build in compartment "sap.com_SAP_ESS_1"
• Synchronization of sources is skipped for Activation with option IGNORE BROKEN DC
• Synchronization of libraries is skipped for Activation with option IGNORE BROKEN DC
• STORE activation build results... finished at 2013-09-09 14:48:15.246 GMT and took 29 s 429 ms

Change request state from PROCESSING to SUCCEEDED

• An incomplete integration in compartment "sap.com_SAP_ESS_1" of buildspace "P01_Xss730_D" has resulted because of errors during request processing!

Request 4752 has been created to re-initialize the compartment

• Change request state from SUCCEEDED to FAILED

    Error! The following problem(s) occurred  during request processing:

    Error! Communication error when performing integrations. Integration failed with unexpected CONFLICT status [com.sap.dtr.client.lib.protocol.entities.ErrorEntity@6ee3a062]. Request FAILED.

REQUEST PROCESSING finished at 2013-09-09 14:58:29.971 GMT and took 12 m 54 s 910 ms

No build logs available for the request.

I don't know whats happening.

Regards,

Gregory.

[Former Member]

I'm still having the problem.

Looking for a solution I've found (into DTR) there are 28510 open collisions. All collisions are into .XLF files.

Solving those collitions will help me solve the import problem? If so, how can I solve them?

I'm trying to solve them through DTR console (with NWDI_CMSADM user) but it gives me an "Received "404 Not Found" response for the request: REPORT /dtr/" for all commands I try to use.

Please I need some help on this.

Regards,

Gregory.

[ErvinSzolke]

Hi,

try using the DTR console available in this note:

1377679 DTR Console "replicate command" don't work

The note is related to replication, but don't worry about that, just take the DTR console app available as an attachment inside this note. No need to deploy it, just extract the file, and you can use it right away from any locations (even from your laptop if it has a working connection to the server where DTR resides).

The other note crosses my mind when it comes to too many colisions is the note:

779323 Mass resolution of Integration Conflicts in DTR

I hope this helps.

Regards,

Ervin

[Former Member]

Hi Ervin,

Thanks for your answer I've downloaded DTR console from note #1377679 and it works I can esolve one conflict but there are 28509 conflicts.

When I try to read note #779323 get the error message "The requested SAP Note is either in reworking or is released internally only".

Is there any way to solve multiple conflicts? If so, how can I do this?

Regards,

Gregory.

[ErvinSzolke]

Hi Gregory,

first of all I am now wondering whether this track was already in use, or this is a new track.

If this is totally new, then it would be much easier to simply create a new one (or delete DTR workspaces of the current one and then resave the track and reimport). Normally with brand new tracks no conflicts should appear, so I assume this track was already in use right?

If you used the track, and you really want to do mass conflict resolution, then here are my thoughts about this approach:

Indeed the note 779323 is internal, and also very old in the same time, so we keep it internal. I talked to my colleagues to write a more up-to-date note that is addressing the mass resolution of integration conflicts.

Until that you can use the following notes this way:

Ensure that you have no naming conflicts as per 1560064, and then you can do mass resolution using the note 1672262 (I know it is from the component CRM, but the command can be used).

Regards,

Ervin

[Former Member]

Hi Ervin,

This is a new TRACK, indeed is the third time I try creating a new TRACK (through NWA Wizard) so all the problems and errors I'm facing importing SAP_ESS 633 SC are pretty weird to me. That's why I'm trying to solve DTR conflicts.

I assume the problem is related to there was a TRACK created with SAP_ESS 603 SC when the portal was in version 7.01 (the TRACK was created but never used), now the portal is in version 7.30 and that's why I'm trying to import SAP_ESS 633 (now we need to do some changes).

Referent to the conflicts mass resolution, I've found a way to get a list of all conflicts and create a script with the command "discard -col -cip" for all of them. The script is still running so when it ends I will see if the conflicts were solved and if the import runs. If the problem persists I will see those notes you recommend.

Regards,

Gregory.

[Former Member]

Hi Ervin,

As I say before this is a new TRACK and I've tryed to create new TRACKs three times.

I've stopped my script and follow the recommended notes instructions to solve DTR conflicts and it works fine.

Then I've executed the SC import once again and once again activation request fails, restarting the server, setting the build space on PRIVILEGED input mode and adding an INIT_COMPARTMENT request to CBS. Activation log is attached.

I don't know what else to do and I need to import the SC to implement some modifications.

Regards,

Gregory.

CBS Request Log.txt.zip

[Former Member]

Sorry,

I've forgot to attach de CBS-make log (the one accessed by CMS web GUI) in previous post.

Gregory.

CBS-make.log.txt.zip

[ErvinSzolke]

Hey Gregory,

I am wondering why you have OOM, perhaps it'd help if you could cast your eye on the note

1001502 - OutOfMemory error during CMS import on Oracle 10g database

that deals with similar issues. Perhaps decreasing the maxbatchcount parameter as pointed out by the note makes some improvement.

Best Regards,

Ervin

[ErvinSzolke]

Hi,

fyi, we have just released a new note :

#1912125- Mass resolution of Integration Conflicts in DTR

Regards,

Ervin

[Former Member]

Hi Ervin,

We are on NW 7.30 and Oracle 11.0.2.3, do I need to apply the note #1001502.

The new note summarizes all the steps for mass resolution of DTR conflicts, thanks.

Now I'm having an extra issue: the INIT_COMPARTMENT CBS request stays in status PROCESSING for about 16 hours. I've restarted the CBS service, then the server and still processing.

Regards,

Gregory.

[ErvinSzolke]

Hi Gregory,

yes, I suggest you to decrease the maxbatchcount as described in the note.

Mass conflict resolution: you are welcome 😉

Regarding the "hanging" cbs state, you can try this approach:

http://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=247137217

Regards,

Ervin

[Former Member]

Hi Ervin,

After some problems deploying the latest version of DI_DTR SC I've successfully applied note #1001502 adjusting the value of maxbatchcount parameter. Then execute the import again and fails again doing exactly the same described above.

The logs also are the same as attached before.

Regards,

Gregory.

[ErvinSzolke]

Hi,

could you please double check your system as per the note:

#1248926-- AS Java VM Parameters for NetWeaver 7.1+ based products

Regards,

Ervin

[Former Member]

Hi Ervin,

I've already cheked that note.

W've opened an OSS case with number 12005040900000351032013.

Regards,

Gregory.

[Former Member]

Hi,

After a long interaction with SAP (OSS case number 12005040900000351032013) the import works.

Regards,

Gregory.

[ErvinSzolke]

Hello Gregory,

I am glad to see that the problem has been resolved in the meantime, and I am also very thankful that you shared this to us.

For the record -- since other customers might also face this issue in future -- the problem was apparently a communication issue between DTR and CBS (which was caused either due to an OOM or due to ICM related problems addressed in KBA 1750758).

Best Regards,

Ervin