Importing SCA Via CMS

[Former Member]

Hi,

Quick question regarding importing SCA's into a runtime enviornment via CMS.

Lets assume that ACTIVITY-A was checked in, activited, deployed into development, QA, assebled and now waiting for import into production.

Before i import ACTIVITY-A into production, i checked in and activated ACTIVITY-B. ACTIVITY-B has also been deployed into development, QA, been assembled and now waiting for import in production.

So now i have two changes waiting for import into production i.e. ACTIVITY-A and ACTIVTY-B.

Will importing just ACTIVITY-B be sufficient? I.e. does ACTIVITY-B also contain the changes made for ACTIVITY-A? in that case instead of deploying both into production, i can just deploy ACTIVITY-B, is that correct?

[Former Member · Accepted solution]

Hi,

Changes made in one activity will not be captured in the successor activities.In my opinion Activity A wil contain it's change and ActivityB will contain it's own change. You will have to deploy both.

Akshatha

[Former Member · Accepted solution]

I'm sorry to say, but Akshatha's answer is incorrect: Assembly takes all active components from the Consolidation stage. Since activity A (actually Transport request A) has already been activated and assembled, it's part of the active workspace of the Consolidation stage.

The Assembly done for activity B (transport request B) contains ALL active components from the Consolidation Stage and thus also contains the changes done in activity A.

You will also notice that CMS will automatically mark the Assembly for activity A as 'outdated' if you import both assemblies into the QA/Production stage.

PS. QA (Test) comes AFTER the Assembly stage. In case you've connected your QA system to the Consolidation stage, I would advise to move it to the Test stage. This way you are testing the same Assembly on QA that will go to Production.

Edited by: Pascal Willemsen on Feb 26, 2008 9:09 AM

[Former Member · Accepted solution]

HI norman,

I am sorry. Pascal is right. I wrote with respect to cons queue in my mind..With respect to assembly pascal's explanation is perfect.

Akshatha

[Former Member · Accepted solution]

Thanks for the information Pascal. I think ive already awarded points for this.

[Former Member]

Please assist

[Former Member]

Your last statement is correct. Remember that you are building a complete Software Component. If there's something in there that you do not want (activity 2) than you will have to remove it first. Think of it as if activity 2 contained a functional bug.

[Former Member]

I have another question regarding this.

1. Let say that i push acitivity-1 through CMS all the way into production (dev -> consolidation -> assembly -> test -> approval -> production)

2. i push activity-2 all the way into test and reject from the approval queue

3. i push activity-3 all the way into production

The problem is that acitivity-3 will also contain that changes for activity-2 even though activity-2 was rejected.

Is this a bug in CMS or by design? you are forced to import even the changes you dont want imported.

Im thinking the only resolution to this will be once you reject activity-2 from approval, you push an acitivity which undo's the changes for activity-2 and then you can push acitivity-3. Is the the correct approach or is their any simpler way to handle this?