Activities Are Not Released into CMS for Transport

[Former Member]

I need your guidance on my current scenario. Currently, we (developers) do not release our activities that created in our NWDS after making our code change. We only do the check-in of the code and sometimes activate the activity. We did not release our transport in NWDS because we actually use the EAR generated from the build in our NWDS and then deploy it directly to the server (Dev, Test and Prod). Therefore, there will be NO activities available in CMS to execute.

Now, there is a request that they would like the CMS to be executed which means to transport if any activities that we've release. As you can see, the developers never release the activities but only check-in the codes because they're deploying the EAR file directly from the NWDS to the corresponding server (Dev, Test and Prod).

So, my questions are when the CMS is being executed, what will happen?

1. Will all the changes that we have made and deployed via the EAR File last time will be overwritten?

2. If yes, what should be done to resolve this?

[shreyas_pandya · Accepted solution]

Hi Shreya,

##########################################################################################

For providing answers to your previouse questions, please go through the following scenario.

Here we assume that you have a track ready with only one runtime system configured as development, and you have imported Development configurations from SLD into your Developer studio.

1) Now you make changes in your DC, which results in the activity creation (in other words Checking Out from DTR basically)

2) You right click your DC and choose the option DC-->Build

the above step creates a local .ear of you DC.

3) You righ click your DC and choose the option DC-->Deploy

the above step actually deploys the .ear file onto the server using the developers id.

Now if you run your project it will show the last modification that you had done.

4) Now you check in the activity that was created in Step 1.

the above step will copy the entire source code from the local workspace of your track and dump it into the DTR Workspace of your track on the server.

5) Now you activate the activity from the activation view, this will trigger the CBS to build the newly checked in source code in DTR, If the build is successful then then you can say the changes are actually deployed in the server and it will reflect the same changes that your activity was holding.

(Please Understand that this deployment happens via the Usesr ID that you have maintained in the runtime system of your track)

6) Now from Transport view in NWDS if you release the same activity then it doesn't trigger any buid or deployment related process, it will just put your released activity into the consolidation system of your track in CMS.

7) And afterwards you can take it forward till assembly and create a .sca file out of it. and deploy it in the target systems.

Hope the above steps will clear your doubts related to deployements.

##########################################################################################

For providing answers to your Latest question related to Creation of a new track.

As you have said that all your important source code is in your current track, you can make a copy of this current track

If you want to copy a track, proceed as follows:

...

1. Select the track that you want to copy and choose Save As.... The Save As dialog

box appears.

2. Enter a new track ID and track name, and a description for the copy and choose Save.

##########################################################################################

Hope this will help you...

Regards,

Shreyas Pandya

[Former Member · Accepted solution]

Dear Shreyas,

Can I know what is the difference if I deploy EAR file directly to TEST Server rather than releasing it activity for consolidation?

Sincerely,

SE

[shreyas_pandya · Accepted solution]

Dear Shreya,

Deploying EAR directly into TEST system will directly deploy your ear into the TEST system, which i would say is totaly a wrong practice because in TEST server logicaly speaking we always transport the code from the Development server, we NEVER directly deploy the source code in test server, if people would practice this scenario then there will not be any difference between the development server and test server.

Usually to control this practice (i.e. direct deployment into quality) we remove the deployment specific UME actioins from the developers id in test server.

The reason why we follow this practice is because we make sure that the code that is transported in test server is never altered & no one can play around any tricks with the trnsported version. This complies that the quality assurence team can complete their testing smoothly in the TEST server, on the genuine application developed by the developers.

Now comming back to your question.

The difference is as follows...

1) As I have explained previously that straight deployment in the test server is a direct violation of best practices, as it deploys your ear in the test server directly.

2) Now lets understand the second point. If you release your activity (i.e. here we consider that you have Checked In, Activated & Released your activities from Open activities View, Activation View & Transport View respectively in NWDS).

Now the SC with the Activity Specific changes is now Queued Up in NWDI-CMS Consolidation Tab.

Please refer to the point number 5 of my previouse post, where i have clearly mentioned that on activation step the deployement will happen in DEVELOPMENT SERVER (and not in test server), via the id that is maintained in the Runtime Sytems for development systems.

3) Now understand that Importing into consolidation step is like deploying in consolidation system, so for your track if you have checked the consolidation system as one of the 4 runtime systems, then at import into consolidation step will actually deploy your changes in the consolidation system.

4) I know this would sound little confusing but to remove your confussion, let me clarify that NWDI supports transportation across maximum 4 different runtime systems. So In your landscape if you have 3 servers like Development, Test and Production server.

then you can define 3 runtime systems (Development, Test & Production) for your track and each runtime system will have its own deploymentment specific information like deploy controller Host, Port Number, Deploy User & Password.

5) Now in such case where you don't have any consolidation system defined, the activities that you release from the NWDS Transport View will still get queued up in the NWDI-CMS Consolidation Tab and then when you import those activities, it will not do anything, it will just queue those activity now in the NWDI-CMS Assembly Tab.

6) Assemble Components will create a new .SCA that will get queued up in the NWDI-CMS Test Tab.

7) If you import the queued up component in NWDI-CMS Test Tab then it will now actually deploy your changes in the Test Server (using the Information which would have been maintained in the Test Runtime system of your track)

😎 Now your SC will be queued up in the NWDI-CMS Approval Tab, if you approve from this tab then, the SC will get queued up in the NWDI-CMS Production Tab.

😎 If you Import the queued Up SC in Production Tab, It will actually deploy your changes into the Production Server (using the Information which would have been maintained in the Production Runtime system of your track)

I hope you have a clear picture now...

revert in case if you need any further clarification.

Regards,

Shreyas Pandya

Edited by: Shreyas Pandya on Jul 15, 2010 4:16 PM

[Former Member · Accepted solution]

What your saying in point 5 is not true: During Import in the Consolidation stage the activities contained in those transports will be imported in the inactive version of the Consolidation buildspace. Then CBS performs a build (again, similar to activating an activity from NWDS) and if this is successful, the code changes will be integrated into the active Consolidation buildspace.

Assembly will take the results of these Consolidation builds to build up the SCA.

[shreyas_pandya · Accepted solution]

Dear Shreya,

Please consider Pascal's inputs. He is correct, i was wrong on point number 5.

Dear Pascal,

Thank you so much for your correction. I am really pleased to get your expert inputs. I would need to learn lot of things from the experts like you in here.

I have one doubt here, which i would like to explain with a scenario explained below...

1) I have 4 runtime systems defined in my track defined with their respective deploymentment specific information like deploy controller Host, Port Number, Deploy User & Password correctly .

Develoment (Host Name : hostDEV),

Consolidation (Host Name : hostCONS)

Test (Host Name : hostTEST),

Production (Host Name : hostPRD).

2) In the above described scenario what will happen when i will release my activity from NWDS and then import it into the NWDI-CMS Consolidation Tab? will it actually deploy the new changes into the hostCONS?

Basically i want to know...

What exactly the Consolidation System means?, and where is it physically present?

Is it present in the development server(hostDEV) itself {i.e. is it tightly coupled with Development Sever} or it is all together a separate host system (Isolated Server) like Test Server (hostTest) & Production Server(hostPRD)?

Thanks in Advance,

Shreyas Pandya

Edited by: Shreyas Pandya on Jul 15, 2010 5:46 PM

[Former Member · Accepted solution]

Yes, this will deploy the new changes to the Consolidation system, but ONLY if the CBS build was successful.

The Consolidation system is ideally a separate host system and you can use it to consolidate (duh! ) your release (let's say 1.0): The Consolidation stage enables developers to fix issues found during testing in the Test stage or even Productive issues for release 1.0, while developing even newer functionality/patches, which should be part of (patch)release 1.1 in the Development stage. Once release 1.1 moves to Consolidation, you're entering the upgrade path to release 1.1: From that point on you will not be able to fix issues found in release 1.0.

This is all possible because the Consolidation stage has a buildspace attached ("Domain_TrackID_C"), just like the Development stage, with a corresponding Development Configuration. You can import this configuration into your NWDS to make changes to the code available in the Consolidation stage.

In case you make changes in the Consolidation buildspace, these will be automatically propagated back to the Development buildspace if activation (the CBS build) is successful. In case the Consolidation activity contains resources that have already been modified in the Development buildspace, this may lead to an integration conflict (the Consolidation changes cannot be automatically copied to the Development resource(s)), which you can then resolve using the Integration Conflicts view of NWDS.

Kind regards,

Pascal

[shreyas_pandya · Accepted solution]

hi Pascal,

Thank you so much for resolving all my doubts, now the entire picture is clear.

Regards,

Shreyas

Edited by: Shreyas Pandya on Aug 30, 2010 1:49 PM

[Former Member · Accepted solution]

So, your question has been answered?

[shreyas_pandya · Accepted solution]

The Thread was created by Shreya Eknath.

Hi Shreya, please mark the thread as answered, if all your queries are resolved.

Regards,

Shreyas Pandya

[Former Member]

1. Yes

2. What's there to be resolved?

[Former Member]

Dear Pascal,

Because the activities were not yet released. Therefore, I wonder if the changes will not be overwritten after the consolidation in CMS. As you know, there are no activites in CMS, so I wonder how it will overwrite my changes in the EAR.

Also, I want to figure out if there is anyway that can do a full compilation of the whole DC since we have codes check-in?

Sincerely,

SE

[dao_ha]

Hi Shreya,

I assume that you have the NWDI setup properly with your tracks and SCs/DCs, just that you didn't use it before (since you deployed directly onto the runtime systems); now you want to start using NWDI for transporting developed applications and change management. If so, just to elaborate on what Pascal mentioned:

1. If your DTR is up-to-date (i.e. you checked in your last modifications) then your EAR will be overwritten with the latest version.

2. As a result, there's nothing to "resolve" because there's no problem. In other words, the CMS just re-deploy your files (instead of you re-deploy the same files direclty onto your runtime systems).

Also, when your checked-in DCs moving through assembly, your DCs/SCs would be re-built and assembled (if that's what you meant by "full compilation").

Please try not to cross posting. And, please provide as much details as possible (your landscape, versions, etc.); it'd be easier/faster for everyone who tries to help.

Regards,

Dao

[Former Member]

Dear DAo Ha,

Thanks a lot for your valuable inputs! It helps a lot.

You mention that the CMS will overwrite the EAR file with the codes that I check-in. My situation is I have the codes check-in but the activities was not released. In that case, does the CMS still able to overwrite the EAR File with the code I check-in but was not released?

SE

[dao_ha]

Hi Shreya,

Sorry, I forgot to mention that, first of all, you'll need to check-in, activate (since you mentioned that you only activate "sometimes") and release to transport all your activities from NWDS; otherwise, there's nothing in the Transport Studio (NWDI) to really ... transport

I believe, as a good practice, you should always activate your activities to update the active workspace in the DTR and that you should only check out the codes (for modification) from the inactive workspace. Maybe someone can correct me here if I'm wrong.

Regards,

Dao

[Former Member]

Dao,

You're entirely correct about the fact that developers should always activate their activities after check-in and check that this activation is successful. This is because activation triggers a build by the CBS server ensuring that anyone who checks-out the code will be able to work on it. A developer could for example reference some local jars that he/she has not made part of the DTR activity. This will build without problems on this developer's system, but not on the CBS server or another developer's system.

Kind regards,

Pascal

[dao_ha]

Hi Pascal,

Thank you very much for your confirmation/clarification. I've always appreciated and valued your inputs since I've learnt so much from them.

Best regards,

Dao

[Former Member]

Dear Dao & Pascal,

Actually the Basis are planning to create a New Track because of the NWDI upgrade. I don't think it's a landscape upgrade.

Dao/Pascal, can I check with you that if they're really going to create a new track, I've a concern here. Because all the code change that I did is located in the current track. I have all the activities check-in and released. However, I am not sure when the new track is created, whether all the changes that I did earlier in the current can be deployed fully into the new track.

Can you give me your thoughts?

Sincerely,

SE

[dao_ha]

Hi Shreya,

I'm afraid I won't be able to have any meaningful inputs here without knowing more the details about your landscape and your Basis' plan. Will the NWDI be upgraded from which SP level of NW 7.0 to which version/SP level? Will the NWDI stay on the same machine or will the new version be installed on a new host? When you said you "don't think it's a landscape upgrade.", does it mean there'll be no change to the runtime systems? Are you part of the planning team or do you have any say in this "upgrade" at all (since you're not so sure about what's going on)? If not then I think the matter is out of your hands

Again, it'll be beyond my understanding to see why there's a need to create a new track (of the same SCs) just because there's an SP upgrade of the NWDI and there's no change to the runtime systems. I'm definitely missing something here. Anyway, I'm sure your Basis's plan will ensure that your deployed DCs/SCs would work after the upgrade.

Regards,

Dao