cancel
Showing results for 
Search instead for 
Did you mean: 

no automatic redeployment of dependednt DCs

Former Member
0 Kudos

Hi

I am running NW04 SP9

I have noticed that if I change a DC (for example an EJB DC) in a way that does not impact its PP, then the EAR DC that contains it does not get redeployed automatically by the NWDI (as it is supposed to)

As a result, my fix is not present on the Consolidation system, and of course, the Test and production systems.

As a workaround, I have found that if I make the PP of the EAR 'dirty' (for example, create an additional 'fake1' PP) then the EAR DOES get redeployed.

Q1. Is this a know issue with NW04 SP9?

Q2. Is there anyone here working with NW04 SP9 that does not have this problem?

Q3. Is there anyone here working with NW04 SP14 or SP15 that does not have this problem?

Thank you

Zach Engel

p.s.

I have an open CSN about this

no reply there yet...

<a href="https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/smp_custmsg/main.do?event=LOAD&smpsrv=h">CSN 0120025231 0001708251 2005</a>

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

the log said that internal request 715 was created to build the EAR

i found this request in the CBS

here is the log for req 715

Build Plugin Version: 1.6.3 (630_VAL_REL) from 20 October 2004 01:11:33

Start: 04.01.2006 05:59:43

Temp dir: /usr/sap/J01/JC00/j2ee/cluster/server0/temp/CBS/56/.B/719/t/3CD2EADB9D674A4C839E905B12192051

clean:

prepare:

[mkdir] Created dir: /usr/sap/J01/JC00/j2ee/cluster/server0/temp/CBS/56/.B/719/t/3CD2EADB9D674A4C839E905B12192051/jars

build:

[copy] Copying 1 file to /usr/sap/J01/JC00/j2ee/cluster/server0/temp/CBS/56/.B/719/t/3CD2EADB9D674A4C839E905B12192051/jars

[mkdir] Created dir: /usr/sap/J01/JC00/j2ee/cluster/server0/temp/CBS/56/.B/719/DCs/checkpoint.com/cmn/test5/noredeploy/ear/_comp/gen/default/src/java

[zip] Building zip: /usr/sap/J01/JC00/j2ee/cluster/server0/temp/CBS/56/.B/719/DCs/checkpoint.com/cmn/test5/noredeploy/ear/_comp/gen/default/src/java/src.zip

[echo] Create deploy file checkpoint.comcmntest5noredeployear.ear

[jarsap] Info: JarSAP version 20040427.1000

[jarsap] Info: JarSAPProcessing version 20040406.1800 / JarSL version 20040702.1400

[jarsap] Property jarsap.info.dir is not set.

[jarsap] Building: /usr/sap/J01/JC00/j2ee/cluster/server0/temp/CBS/56/.B/719/DCs/checkpoint.com/cmn/test5/noredeploy/ear/_comp/gen/default/deploy/checkpoint.comcmntest5noredeployear.ear with compression

Build ok

End: 04.01.2006 05:59:43 (Duration: 0 seconds)

seems like even though the build suceeds the CMS does not try and deploy the result.

any idea why?

Former Member
0 Kudos

Maybe another bug in SP09...

Did you try the Trigger Automatic Deployment in TCS?

Former Member
0 Kudos

TCS shows nothing on queue

Former Member
0 Kudos

Then everything has been processed now. (In one of your previous posts in this topic, you had some requests in the queues).

Former Member
0 Kudos

as far as builds, yes, everything has been processed.

but where do i see that the EAR built (as the result of the internal request) is deployed?

Former Member
0 Kudos

This is what I think is one of the most unclear and this-definitely-needs-improvement parts of JDI as it is now.

First of all, deployment is done asynchronously and the only way to monitor it is to figure out the request number that is used for deployment. If you open the SDM log of your import it'll show some follow-up request (if you're lucky...). Use that requestid and it's buildspace in the bottom part of TCS to determine the status of the deployment.

Former Member
0 Kudos
sid-desh
Advisor
Advisor
0 Kudos

Hi Zach,

When you change the code in the EJB module and activate it the EAR and EJB module will both get built and then when you release the activity it will be available for import into the Consolidation system.

Now i am not sure what you mean by automatic deployment. Is it that when you import the activity in the Consolidation system it does not get deployed. In this case you should try checking the deployment log.

Regards

Sidharth

Former Member
0 Kudos

Yes, when I import the activity in the Consolidation system it does not get deployed.

I checked the SDM-log.

here is what it says:

<i>

SAP Change Management Service

Software Component checkpoint.com/TIMEOFF_2

Version DEV_TIMEOFF6_D.14

Label Dirty TO BE 3

System TIMEOFF6-Consolidation

Step SDM-deploy

Log /usr/sap/JTrans/CMS/log/TIMEOFF6_C@DEV/TIMEOFF6_C@DEV200512192102040498SDM-deploy.log

Info:Starting Step SDM-deploy

Info:empty list of archives for deployment: nothing done

Info:Step SDM-deploy ended with result 'not needed'</i>

That is exactly my problem.

it thinks there is nothing to deploy

sid-desh
Advisor
Advisor
0 Kudos

Hi Zach,

Can you also check in the TCS deployer whether you are able to see your request. It may happen that CBS is not able to communicate properly which requests it wants to deploy.

Regards

Sidharth

Former Member
0 Kudos

You can access the TCS Deployer using the following URL:

http://<servername>:<port>/TCS/Deployer

Former Member
0 Kudos

SAP replie my CSN

it is a bug in NWDI SP9

SP15 fixed it

Former Member
0 Kudos

Thanks for the info

Former Member
0 Kudos

Hi

I went to the TCS Deployer as you suggested,

and this is what i see:


<b>This is TCSDeployServlet Version NW6.40 SP08 Patch level 00</b> 

Heartbeat Check

Return value of heartbeat check: O.K. 

Buildreqeuests in queue
buildspace name = DEV_APPL_C
corresponding buildrequestids in queue = [486, 487, 488, 489, 496, 497, 498, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509] 

buildspace name = DEV_APPL2_C
corresponding buildrequestids in queue = [517, 526, 528, 532, 534, 536, 542, 544, 552, 557, 558, 561, 567, 569, 573] 

buildspace name = DEV_TIMEOFF6_C
corresponding buildrequestids in queue = [355, 356, 360, 362, 364, 366, 371, 373, 377, 390, 392, 396, 398, 400, 402, 404, 406, 414, 418, 422, 426, 428, 433, 437, 522] 

buildspace name = DEV_FRMWRK0_C
corresponding buildrequestids in queue = [330, 342, 344, 375, 382, 385, 386, 388, 412, 416, 420, 424]

Can you explain what is the meaning of these results?

Is this supposed to be empty in normal situation?

Former Member
0 Kudos

Do you have the "Disable Automatic Deployment" checkbox ticked in your Consolidation runtime system for these tracks? If so, what you see in TCS is the effect of this checkbox...

You can trigger these deployments by entering the corresponding buildspaces (one by one) in the Trigger Automatic Deployment section of TCS.

Former Member
0 Kudos

The check box is not Selected

meaning I am not disabling automatic deployments

and still, when i added an new EJB to an EJBModule,

the sdm log said - nothing to deploy

here is my build log

Request Log - [ 714/DEV_APPL2_C ]

syndrome.checkpoint.com SAP Component Build Server

Build number assigned: 718

Change request state from QUEUED to PROCESSING

ACTIVATION request in Build Space "DEV_APPL2_C" at Node ID: 3,003,750

[id: 714; parentID: 0; type: 4]

[options: IGNORE BROKEN DC, FORCE ACTIVATE PREDECESSORS, FORCE INTEGRATED, IGNORE COMPONENT INTERSECTION]

REQUEST PROCESSING started at 2006-01-04 15:59:15.568

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

List of activities to be activated:

1 activity in compartment "example.org_APPLICATION_1"

dirty test5 EJB(9)

[seq. no 36][created by ZENGEL at 2006-01-04 13:59:12.0][ID ea4f89e87d3911dabbbb000d609aa886]

Analyse dependencies to predecessor activities... started at 2006-01-04 15:59:15.587

Analysing compartment "example.org_APPLICATION_1"

No dependencies to predecessor activities found.

Analyse dependencies to predecessor activities... finished at 2006-01-04 15:59:15.59 and took 3 ms

Analyse activities... started at 2006-01-04 15:59:15.59

Synchronizing component "example.org/appl/test5/noredeploy/ejb" from repository... finished at 2006-01-04 15:59:15.962 and took 98 ms

1 component to be build in compartment "example.org_APPLICATION_1"

Analyse activities... finished at 2006-01-04 15:59:15.977 and took 387 ms

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

"example.org/appl/test5/noredeploy/ejb" variant "default"

Prepare build environment in the file system... started at 2006-01-04 15:59:16.049

Synchronize development configuration... finished at 2006-01-04 15:59:16.05 and took 0 ms

Synchronize component definitions... finished at 2006-01-04 15:59:16.054 and took 4 ms

Synchronize sources... finished at 2006-01-04 15:59:16.093 and took 38 ms

Synchronize used libraries...

public part "default" of component "sap.com/ejb20" ... OK

[PP "default" of DC 93 variant "default"][SC 384][last successfull build: 662]

public part "default" of component "sap.com/jdbc20" ... OK

[PP "default" of DC 85 variant "default"][SC 384][last successfull build: 662]

public part "default" of component "sap.com/jms" ... OK

[PP "default" of DC 141 variant "default"][SC 384][last successfull build: 662]

Synchronize used libraries... finished at 2006-01-04 15:59:16.339 and took 245 ms

Prepare build environment in the file system... finished at 2006-01-04 15:59:16.34 and took 291 ms

===== Pre-Processing ===== finished at 2006-01-04 15:59:16.34 and took 760 ms

===== Processing =====

BUILD DCs

"example.org/appl/test5/noredeploy/ejb" in variant "default"

Public Part "client" has been changed. Dependent components will be marked as DIRTY and re-built later.

Public Part "ejbjar" has been changed. Dependent components will be marked as DIRTY and re-built later.

The build was SUCCESSFUL. Archives have been created.

===== Processing ===== finished at 2006-01-04 15:59:27.628 and took 7 s 140 ms

===== Post-Processing =====

Check whether build was successful for all required variants...

..SKIPPED. Request option "IGNORE BROKEN DC" was given.

Update component metadata...

STORE build results...

"example.org/appl/test5/noredeploy/ejb": store meta-data

"example.org/appl/test5/noredeploy/ejb" in "default" variant is PROCESSED

Change request state from PROCESSING to SUCCEEDED

Analyse effect of applied changes to buildspace state... started at 2006-01-04 15:59:27.756

Handle Cycles...

No cycles detected.

Determine components that have become DIRTY due to the results of this request...

"checkpoint.com/cmn/test5/noredeploy/ear" (variant "default") uses the changed component "example.org/appl/test5/noredeploy/ejb".

Internal Build Request 715 has been CREATED to build the following component:

"checkpoint.com/cmn/test5/noredeploy/ear" variant "default"

Integrate activities into active workspace(s)...

Integration of activities in compartment "example.org_APPLICATION_1" started at 2006-01-04 15:59:27.832

"dirty test5 EJB(9)" OK

Integration of 1 activities in compartment "example.org_APPLICATION_1" finished at 2006-01-04 15:59:28.282 and took 450 ms

Analyse effect of applied changes to buildspace state... finished at 2006-01-04 15:59:28.283 and took 527 ms

Request SUCCEEDED

===== Post-Processing ===== finished at 2006-01-04 15:59:28.284 and took 643 ms

REQUEST PROCESSING finished at 2006-01-04 15:59:28.284 and took 12 s 716 ms