Skip to Content

Errors while deploying ear without comment on NW75SP08 after migrating from JCo2 to JCo3?

Hello,

we change our code from JCO2 to JCO3, everything seems to be fine in build. But now when we deploy our .ear to nwdi errors are shown without cause. (?) Maybe someone can help me?

Here are the Details for one example:

Global [startInitiallyApp] operation of application [xxx/sd~vip~jpa~ear] failed with errors on server process [4665950].

Global [startInitiallyApp] operation of application [xxx/sd~vip~jpa~ear] finished with errors for [79] ms on server process [4665950] [
>>> without errors <<<] [
>>> without warnings <<<].

com.sap.engine.services.deploy.server.TransactionManager

j2ee\cluster\server0\log\defaultTrace_00.trc

#2.0#2017 09 13 15:31:24:188#+0200#Error#com.sap.engine.services.deploy.server.TransactionManager#
com.sap.ASJ.dpl_ds.002038##xxxx/sd~vip~jpa~ear#C0000A4752270D840000008100000FF0#4665950000001052##com.sap.engine.services.deploy.server.TransactionManager#Administrator#648##FF013875CF381006A8F8EF4C4C72DFB1#ff013875cf381006a8f8ef4c4c72dfb1##0#Thread[DeployThread[xxx_sd~vip~jpa~ear],5,Managed_Application_Thread]#Plain##
Global [startInitiallyApp] operation of application [xxxx/sd~vip~jpa~ear] failed with errors on server process [4665950].#

#2.0#2017 09 13 15:31:24:188#+0200#Error#com.sap.engine.services.deploy.server.TransactionManager#
com.sap.ASJ.dpl_ds.0020380##xxxx/sd~vip~jpa~ear#C0000A4752270D840000008200000FF0#4665950000001052##com.sap.engine.services.deploy.server.TransactionManager#Administrator#648##FF013875CF381006A8F8EF4C4C72DFB1#ff013875cf381006a8f8ef4c4c72dfb1##0#Thread[DeployThread[xxx_sd~vip~jpa~ear],5,Managed_Application_Thread]#Plain##
Global [startInitiallyApp] operation of application [xxxx/sd~vip~jpa~ear] finished with errors for [79] ms on server process [4665950] [
>>> without errors <<<] [
>>> without warnings <<<].#

j2ee\cluster\server0\log\system\server_00.log

#2.0#2017 09 13 16:36:32:756#+0200#Info#/System/Server#
#BC-JAS-BTC#scheduler~runtime#C0000A4752270DA60000000000000FF0#4665950000302758#sap.com/tc~je~oauth~app#com.sap.engine.services.scheduler.runtime.mdb.MDBJobDelegateImpl#Guest#0#JTA Transaction : 159745#C3A8CFFA93C411E79DC500505691331D#c3a8cffa93c411e79dc500505691331d#00000000000000000000000000000000#0#Thread[Managed_Application_Thread_38,5,Managed_Application_Thread]#Plain#com.sap.engine.services.monitor.mbeans.MonitorResourceBundle#
Job started on Wed, 13 Sep 2017 16:36:32:748 CEST
, Scheduler: bcf903e2589011e5b7ba2c44fd86de84
, Job ->
, TaskName: DeleteTokensTask
, JobDefName: DeleteExpiredTokensJob
, JobName: DeleteExpiredTokensJob
, TaskId: f952bcbaf77911e6afe300000047325e
, JobId: f0018055989011e79d6d00000047325e
, JobDefId: 488dd8d69b8011e6ca9700000047325e
, Node: Server 00 00_46659
, JMS MessageID: ID:4A6D010000000054-0000000009C8
, Current Attempt: 1
, Attempts Left: 4
, Re-Delivery Delay Interval: 2000 milliseconds#

#2.0#2017 09 13 16:36:32:766#+0200#Info#/System/Server#
#BC-JAS-BTC#scheduler~runtime#C0000A4752270DA60000000100000FF0#4665950000302758#sap.com/tc~je~oauth~app#com.sap.engine.services.scheduler.runtime.mdb.MDBJobDelegateImpl#Guest#0#JTA Transaction : 159745#C3A8CFFA93C411E79DC500505691331D#c3a8cffa93c411e79dc500505691331d#00000000000000000000000000000000#0#Thread[Managed_Application_Thread_38,5,Managed_Application_Thread]#Plain#com.sap.engine.services.monitor.mbeans.MonitorResourceBundle#
Job ended on Wed, 13 Sep 2017 16:36:32:760 CEST
, Job ->
, JobId: f0018055989011e79d6d00000047325e#

Add comment
10|10000 characters needed characters exceeded

  • Yes, thanks, but there is no file with actual data respective the deployment.

  • Then the deployment call does not get to the AS Java.

    Please clarify from where to where you do make this deplyoment: NWDS - NWDI - RTS AS Java or NWDI - RTS .

    In case of NWDI involve, on which tab the import is happening - DEV, CONS, TEST, PROD?

    Please attach the relevant logs from the CMS: open Transport Studio - Details - the failed import and observe the 3 steps:

    Repository Import

    CBS-make

    SDM deployment.

    Where the import fails? Please attach the relevant log.

  • We deploy from NWDS to local Server for testing (DEV). After app working we check-in and go through CMS for integration and productive system deploy (CONS, TEST, PROD). What i can see there are only the 2 log files whose content i post when i deploy. All others are not "updated" for logging. For testing i undeploy DCs in NWDS (they were deleted, nothing visible in NWDS) and make new deployment. After that they are visible, so deployment takes place in some kinds, but still not working.

  • Get RSS Feed

1 Answer

  • Sep 20, 2017 at 02:06 PM

    So, there is local deployment from the NWDS to the AS Java. Sometimes it works, sometimes it does not.

    When it does not work, it should be analysed

    - the .log from the NWDS - SAP note 2078679

    - the deplyoment.x.trc and deployment.log from the work directory of the instance which is configured in the NWDS (SAP AS JAVA)

    When the deployment logs are not updated and there is no error in the .log file, there is a network issue that prevents this deployment.

    In case the AS Java is on virtual machine, please consider (only) the Resolution in this SAP KBA:

    2417079 - Wrong Deployment Variable in CMS

    In case there are multiple NIC adaptors of the server, where the target AS Java of the local deployment is, please consider this SAP note:

    1158626 - P4 connection to ICM on machine with multiple IPs fails

    Add comment
    10|10000 characters needed characters exceeded

    • ... well you did mention the source code is working "as a charm" with JCo 2 . Then it should be considered whether this piece of software might work with JCo3 at all.

      Definitely, it does not seem to be neither a deployment nor a software logistic matter. If JCo3 might be used with this feature, it might be indeed related to either the build-time dependencies or a build error due to incorrect libraries being used.

      It is also possible, the deployable archive to be corrupt or created with some kind of error in the build process.