Skip to Content
avatar image
Former Member

Unable to check in code from NWDS 7.31 to NWDI 7.0

We have migrated NWDS and Portal to 7.31. But NWDI is at 7.0.

Had one custom object, few custom Webdynpro Java components in ESS, and MSS implementation.

1. For the Custom object and for custom Webdynpro Java components, Basis had created 2 separate tracks, which we have migrated, build the DCs in NWDS, all looks good. Deployed the code directly to the Dev server PD1.

Now we have been asked to checkin these activities and activate so that the code gets deployed back to NWDI. Here we are getting the build error. But currently we build the project in NWDS we are not getting any errors. As mentioned the applications are working fine in Dev server after we deploy it directly. But to transport the code to NWDI so that we transport to QA, we are facing this issue.

any help is appreciated.

Thanks

Hima

Below is the error log:

Build number assigned: 102216

Change request state from QUEUED to PROCESSING

ACTIVATION request in Build Space "NDI_MTCATS73_D" at Node ID: 36,434,750

[id: 42,221; parentID: 0; type: 4]

[options: FORCE ACTIVATE PREDECESSORS]

REQUEST PROCESSING started at 2018-04-19 15:41:33.877 GMT

===== Pre-Processing =====

Waiting 3 ms

List of activities to be activated:

1 activity in compartment "XXXX.com_MTE-CATS-CUSTOM_1"

ERP Upgrade 731

[seq. no 3][created by XXXX at 2018-04-17 13:45:55.0][ID 9f2d0fbb3ec511e8910702eabf9df950]

Analyse dependencies to predecessor activities... started at 2018-04-19 15:41:33.892 GMT

Analysing predecessors in compartment "XXXX.com_MTE-CATS-CUSTOM_1"

No dependencies to predecessor activities found.

Analyse dependencies to predecessor activities... finished at 2018-04-19 15:41:33.988 GMT and took 96 ms

Analyse activities... started at 2018-04-19 15:41:33.988 GMT

Development line state verification started at 2018-04-19 15:41:34.205 GMT

Verification of the development line [ws/MTCATS73/XXXX.com_MTE-CATS-CUSTOM/dev/active/] SUCCEEDED

Development line state verification finished at 2018-04-19 15:41:34.209 GMT and took 4 ms

Cache verification, level 2 (Comparison of attributes) started at 2018-04-19 15:41:34.209 GMT

Verification of the following object:

[DC: XXXX.com/cats/emp/timevrfy, group: 0] SUCCEEDED

Cache verification finished at 2018-04-19 15:41:34.227 GMT and took 18 ms

Analyse dependencies to predecessor activities... finished at 2018-04-19 15:41:34.232 GMT and took 168 ms

CHANGE: Development Component "spiritaero.com/cats/emp/timevrfy"

Development line state verification started at 2018-04-19 15:41:34.295 GMT

Verification of the development line [ws/MTCATS73/spiritaero.com_MTE-CATS-CUSTOM/dev/active/] SUCCEEDED

Development line state verification finished at 2018-04-19 15:41:34.299 GMT and took 4 msCache verification, level 2 (Comparison of attributes) started at 2018-04-19 15:41:34.299 GMT

Verification of the following object:

[DC: XXXX.com/cats/mgr/timevrfy, group: 0] SUCCEEDED

Cache verification finished at 2018-04-19 15:41:34.315 GMT and took 16 ms

Analyse dependencies to predecessor activities... finished at 2018-04-19 15:41:34.315 GMT and took 83 ms

CHANGE: Development Component

2 components to be build in compartment "MTE-CATS-CUSTOM_1"

Analyse activities... finished at 2018-04-19 15:41:34.342 GMT and took 354 ms

Calculate all combinations of components and variants to be built...

"XXXX.com/cats/emp/timevrfy" variant "default"

"XXXX.com/cats/emp/timevrfy" variant "default" cannot be built. Activation will fail.

INVALID dependency is declared to public part: default.

[DC 462 variant "default"][SC 2765 "XXXXMTE-CATS-CUSTOM_1"] using [PP default of DC 301 at Build-Time Dependency]

"XXXX.com/cats/mgr/timevrfy" variant "default"

"XXXX.com/cats/mgr/timevrfy" variant "default" cannot be built. Activation will fail.

INVALID dependency is declared to public part: default.

[DC 463 variant "default"][SC 2765 "XXXX_MTE-CATS-CUSTOM_1"] using [PP default of DC 301 at Build-Time Dependency]

Prepare build environment in the file system... started at 2018-04-19 15:41:34.348 GMT

Prepare build environment in the file system... finished at 2018-04-19 15:41:34.348 GMT and took 0 ms

===== Pre-Processing ===== finished at 2018-04-19 15:41:34.350 GMT and took 470 ms

Change request state from PROCESSING to FAILED

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

ERROR! The following error occurred during request processing:Activation failed due to component "XXXX.com/cats/emp/timevrfy" variant "default". The component is BROKEN.

ERROR! The following error occurred during request processing:Activation failed due to component "XXXX.com/cats/mgr/timevrfy" variant "default". The component is BROKEN.

REQUEST PROCESSING finished at 2018-04-19 15:41:34.350 GMT and took 473 ms

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

9 Answers

  • Best Answer
    May 13 at 02:07 PM

    Hello Hima,

    1. please configure a build variant for 7.31 which points to SAPJVM 6. According to the build log the default build variant is used, which for NWDI 7.5 points to SAPJVM8:

    ***

     Analyze request DC BV... started at 2018-05-11 15:44:36.015 GMT
                    ''spiritaero.com/cats/emp/timevrfy'' variant ''default''

    ***

    More directions for this here:

    http://scn.sap.com/community/nwdi/blog/2016/08/24/configuring-jdk-settings-with-nwdi

    2.

    When you have configured what is required in NWA and in the CMS's track, then import all of the SCAs in the CMS - Transport Studio - tab Development.

    3.

    Only when this new build is successful, then re-import the track in the NWDS 7.31 and made the necessary modifications of the source code (a.k.a. "migration")

    Regards,

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 26 at 07:54 AM

    Hello Hima,

    looks like you have broken DCs, please take a look at this guide to see if it helps

    https://ga.support.sap.com/dtp/viewer/#/tree/1333/actions/15969:18487

    If NWDI is on 700, it is fine, more information about this you find in my blog:

    https://blogs.sap.com/2014/03/26/nwdi-vs-nwdi-content/

    Regards,

    Ervin

    Add comment
    10|10000 characters needed characters exceeded

  • May 02 at 12:21 PM

    Hello Hima,

    This end of the Request Log is quite astonishing:

    ***

    ...

    Start build plugin:

    using build plugin: sap.com/tc/bi/bp/webDynpro

    starting build plugin from : /usr/sap/NDI/JC03/j2ee/cluster/server0/temp/CBS/12c/.B/102215/DCs/sap.com/tc/bi/bp/webDynpro/_comp/gen/default/public/webDynpro/

    Build started 2018-04-19 14:23:20 GMT

    Method invocation exception

    Build Stopped

    ...

    ***

    If indeed the NWDI is 7.0 and the track is for 7.30, then it seems like the CBS DOES use the default build variant (which is pointing to SAPJVM4 or even worse to ORACLE JDK 1.4).

    In case what I do write is what it is, please ensure:

    1. SAPJVM6 has been installed on the server box where the AS Java with Development Infrastructure (in particular the CBS) is.

    2. You have implemented the necessary build variant, pointing to SAPJVM6. More details about configuring build variants on NWDI 7.0x in:

    http://scn.sap.com/docs/DOC-16207

    Please pay close attention to

    3.2 CBS Service Properties

    4.4 Add a new Build Option

    Regards,

    Add comment
    10|10000 characters needed characters exceeded

  • May 05 at 08:07 AM

    Hello Hima,

    1.

    Indeed CMS 7.0 SPS9 is a very old piece of software.

    As James has correctly pointed out, the Build Variant tab was introduced in CMS with version 7.0 SP 13.

    2.

    A last resource of a workaround might be to try changing the XML of the development configuration manually. The Procedure is:

    2.1.Select the track that you want to edit in the track list. CMS displays the track data on the Track Data tab page.

    2.2.To switch to change mode, choose Change.

    2.3.Change the data according to your requirements and choose Save. In your case, select "View/Edit XML Content".

    When you do add the build variant for SAPJVM6 in the XML, you have to implement also the other configuration in the Visual Administrator as per http://scn.sap.com/docs/DOC-16207

    Again, please pay close attention to point 3.2 CBS Service Properties

    3.

    Yet, it is not certain whether the CBS will accept this manually changed XML. In case the build is not successful (with manually changed XML), please cross check whether the manually-defined-build-variant is "transferred" to the CBS. The development configuration, having sent to the CBS might be seen in a browser when you do type the following URL (substituting <xxx>with values as per your scenario)

    http://<CBS-host>:<CBS-port>/tc.CBS.Appl/archiveapi?METHOD=GET_BS_CONFIG&BUILDSPACE=<name_of_dev_buildspace>

    where

    <CBS-host> - is the FQDN of the host where the CBS is. I believe it might work also only with host name but yet this is specific for the operation system. (f.e. vmw5899.company.org)

    <CBS-port> - is the http or https port through which you do access the CBS (f.e. the default for http is 50000 and for https - 50001)

    <name_of_dev_buildspace> - is the name of the development CBS buildspace. This is a string which does consist of 3 parts "name of the CMS domain", "name of the track" and 1 letter pointing out whether this is DEVELOPMENT or CONSOLIDATION. These 3 parts are connected with underscore character "_". You do face problem with the DEVELOPMENT buildspace, so a sample might be f.e. NDI_devconftrack_D .

    The above mentioned method you might use, in future, to cross check what kind of development configuration is sent to CBS when you do face build problems. This is a useful way to examine briefly, what is ordered to the CBS to do.

    4.

    If the build variant is transferred to the CBS (and the build with the correct SAPJVM6 is not successful), then it is not only the missing build variant in CMS, but also CBS 7.0 SPS9 is not design to work with a different JDK then the default one (SAPJVM4). Else, the CMS just can not send the build variant to the CBS. In both cases the fixes are delivered in 7.0 SPS 13 and above. Downport of these fixes to SPS9 is not possible due to out-of-support policy for release NW AS 7.0x .

    5.

    I hope these directions might help you. In case you might not build with SAPJMV6 - the upgrade is NOT an option. In case of upgrade, it is better the NW AS Java, where the NWDI is, to be upgraded to 7.50 . This is due to the support of 7.50 will last till 2024, while the support for 7.1-7.4 versions will end on 31st of December 2020.

    Regards,

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 26 at 06:50 PM

    Thank you Ervin,

    But we are able to deploy the same code to the server. And except for the standard components, no other components are showing as errors when we try to checkin the code and activate. The build log is shown below. All the standard components only and only warnings...

    Development Component Build (2018-04-19 14:23:19)

    Component name: cats/emp/timevrfy

    Component vendor: XXXX.com

    SC compartment: XXXX.com_MTE-CATS-CUSTOM_1

    Configuration: NDI_MTCATS73_C

    Location: NDI_MTCATS73_C

    Source code location: http://pwic610:50300/dtr/ws/MTCATS73/XXXX.com_MTE-CATS-CUSTOM/cons/active/DCs/XXXX.com/cats/emp/timevrfy/_comp/

    DC root folder: /usr/sap/NDI/JC03/j2ee/cluster/server0/temp/CBS/12c/.B/102215/DCs/XXXX.com/cats/emp/timevrfy/_comp/

    DC type: Web Dynpro

    Host: pwic610.corp.XXXX.com

    DC Model check:

    All used DCs are available locally

    validating dependency to build plugin "sap.com/tc/bi/bp/webDynpro"

    validating dependency to public part "default" of DC "sap.com/tc/cmi"

    validating dependency to public part "default" of DC "sap.com/tc/ddic/ddicruntime"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated public part default of DC sap.com/tc/ddic/ddicruntime(sap.com_FRAMEWORK_1).

    validating dependency to public part "default" of DC "sap.com/tc/ddic/metamodel/content"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/tc/ddic/metamodel/content(sap.com_FRAMEWORK_1) by using its public part default.

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated public part default of DC sap.com/tc/ddic/metamodel/content(sap.com_FRAMEWORK_1).

    validating dependency to public part "default" of DC "sap.com/tc/wd/webdynpro"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/tc/wd/webdynpro(sap.com_WD-RUNTIME_1) by using its public part default.

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated public part default of DC sap.com/tc/wd/webdynpro(sap.com_WD-RUNTIME_1).

    validating dependency to public part "default" of DC "sap.com/tc/logging"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/tc/logging(sap.com_ENGINEAPI_1) by using its public part default.

    validating dependency to public part "default" of DC "sap.com/tc/wdp/metamodel/content"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/tc/wdp/metamodel/content(sap.com_FRAMEWORK_1) by using its public part default.

    validating dependency to public part "default" of DC "sap.com/com.sap.aii.proxy.framework"

    validating dependency to public part "default" of DC "sap.com/com.sap.aii.util.misc"

    validating dependency to public part "default" of DC "sap.com/com.sap.exception"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/com.sap.exception(sap.com_ENGINEAPI_1) by using its public part default.

    validating dependency to public part "default" of DC "sap.com/com.sap.mw.jco"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/com.sap.mw.jco(sap.com_ENGINEAPI_1) by using its public part default.

    validating dependency to used DC "sap.com/com.sap.security.api.sda"

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated DC sap.com/com.sap.security.api.sda(sap.com_ENGINEAPI_1).

    WARNING: DC "XXXX.com/cats/emp/timevrfy(XXXX.com_MTE-CATS-CUSTOM_1)" depends on deprecated public part default of DC sap.com/com.sap.security.api.sda(sap.com_ENGINEAPI_1).

    DC model check finished with warnings.

    Start build plugin:

    using build plugin: sap.com/tc/bi/bp/webDynpro

    starting build plugin from : /usr/sap/NDI/JC03/j2ee/cluster/server0/temp/CBS/12c/.B/102215/DCs/sap.com/tc/bi/bp/webDynpro/_comp/gen/default/public/webDynpro/

    Build started 2018-04-19 14:23:20 GMT

    Method invocation exception

    Build Stopped

    Thanks

    Hima

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    May 01 at 01:53 AM

    Hi Ervin,

    Can you please help? I am still having the issues. We did the Initiate compartments, and after that we build the components, and check in the code. But we are having the broken DCs still.

    I am completely new to Portal, also NWDS WDJ.

    Thanks

    Hima

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    May 03 at 03:29 AM

    Thank you Milen Dontcheff.

    Here is our build path showing: as I mentioned we are doing the migration from 7.00 NWDS to 7.31.

    BUILD_TOOL_JDK_HOME - /usr/java6
    JDK_HOME_PATHS - JDK1.3.1_HOME=/usr/java14_64;JDK1.5.0_HOME=/usr/java5;JDK1.6.0_HOME=/usr/java6;default=/usr/java6

    Can you please let me know if anything wrong.

    Thanks

    Hima

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    May 03 at 03:33 AM

    Thank you

    Our build path is showing as below:

    BUILD_TOOL_JDK_HOME - /usr/java6

    JDK_HOME_PATHS - JDK1.3.1_HOME=/usr/java14_64;JDK1.5.0_HOME=/usr/java5;JDK1.6.0_HOME=/usr/java6;default=/usr/java6

    is there something wrong?

    Thanks

    Hima

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    May 02 at 05:51 PM

    Thank you for the quick response Milen Dontcheff.

    Where are you seeing that the build variant is pointing towards SAPJVM4 or even worse to ORACLE JDK 1.4. sorry as I mentioned I am completely new to this Portal, NWDS. so asking.


    Thanks in Advance.

    Hima

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Yes, Milen,

      we did opened SAP a message, and this is what they replied.

      Your NWDI is extremely old. 11 years. I think this will be having an impact here.

      Simply patching the DI components won't help in terms of the build variant functionality. An upgrade would be needed for that.

      I will note at this point that 7.0 systems are out of maintenance. If there is some additional bug here that won't be fixed on your current NWDI release version.

      2434460 - SAP NetWeaver 7.0x maintenance ends by 2017

      I don't think the component versions is the issue. You have 7.31 sp21 dependencies configured for 7.31 sp21 runtime system.

      So we are either looking at some way to remove these incorrect dependencies as they are or rebuilding the DCs of the used components with a correct build variant.

      I've attached an NWDI for CE guide for 7.0 sp13 and upwards which definitely references how to set the build variant for the track.

      So possibly the best solution is to simply upgrade the NWDI system to at least sp13 where we know for sure you can configure the build variant.

      Then you can rebuild all the DCs with the correct build variant and then import your development configuration into NWDS.

      If you are going to upgrade, which you should if you intend running this 7.0 system for a long time yet, then it would be best to go for the last sp release for 7.0 which is sp34.

      As mentioned I will discuss with the developers next week about this also.

      best regards,

      James”

      And after receiving this response from SAP, our Basis Admin reply is: to the Project team. So I believe we are NWDI 7.0 SP9 currently.

      Not sure what is a reason to wait until the portal upgrade is complete to upgrade NWDI to 7.31. As James points out below it would be good to upgrade NWDI to the last sp release for 7.0 (SP34), we are on SP9 currently, best would be to go to 7.31. Please let me know.

      I think next week we will be discussing further to upgrade NWDI. will update.

      Thanks

      Hima Akkineni