on 02-14-2012 6:59 PM
Hello
Setting up a NWDI track connection for DEV,QTS, MIRROR and PRD systems.
DEV, QTS and MIRROR - Track 1
PRD - Track 2
How to link the tracks (1 & 2) for transport sequence DEV,QTS, MIRROR & PRD
why you need two track?
two tracks are usually for different release.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
1. yes
> 2 yes
> 3.no, it will be in checkin tab, then you have to drive it through development, consolidation,assembly, test, prd.....
>
This is not the case if the PRD (track 2) track is a runtime only track
why you need two track?
>
> two tracks are usually for different release.
My understanding is that ashishk78 wants to have a PRD only track. If this is the case, Marion's blog should be followed.
Thanks for reply.
Need 2 Track because our Landscape trasnport moves like -
DEV --> TST --> MRR --> PRD
As per my understanding, In run time system , we can configure 3 systems in one Track. So
Track 1 runtime systems tab -
(DEV) - DEV / (CONS)- DEV / (TEST) - TST / (PRD) - MRR
Track 2 runtime systems tab -
Only (PRD) - PRD
Is it right ? Let me know if have any better approach.
Thanks for reply.
>
> Need 2 Track because our Landscape trasnport moves like -
> DEV --> TST --> MRR --> PRD
>
> As per my understanding, In run time system , we can configure 3 systems in one Track. So
> Track 1 runtime systems tab -
> (DEV) - DEV / (CONS)- DEV / (TEST) - TST / (PRD) - MRR
>
> Track 2 runtime systems tab -
> Only (PRD) - PRD
>
> Is it right ? Let me know if have any better approach.
This is fine.
Just make sure you configure track 2 with no DTR workspace or build space as it will be a runtime track only (eg you dont want to assemble any code in this track)
Hi,
NWDI allows you to configure 3 System Landscape or 4 System Landscape.
3 System Landscape
Dev
QA
Prod
In this scenario Dev Runtime system is your Dev system, Consolidation runtime system is blank, Test runtime system is your QA system and Production runtime system is your prod system.
4 System Landscape
Sandbox
Dev
QA
Prod
In this scenario Dev Runtime system is your sandbox system, Consolidation runtime system is your Dev system, and Test runtime system is your QA system and Production runtime system is your prod system.
I hope this helps.
Cheers-
Pramod
> 4 System Landscape
> Sandbox
> Dev
> QA
> Prod
>
> In this scenario Dev Runtime system is your sandbox system, Consolidation runtime system is your Dev system, and Test runtime system is your QA system and Production runtime system is your prod system.
>
The problem with the above scenario is that the DEV runtime is before assembly. Ideally, testing (and sign-off) should be done after the SC has been assembled, hence the need for two tracks in this particular case.
Hi ashishk78,
Understood your problem very clearly.
Here goes the clarification.
Before I start I would like to share something that will shed some light on the background. There are many possibilities of NWDI implementations.
In some scenarios NWDI Usage type (Basically 3 Software components DI_CMS, DI_DTR & DI_CBS) are hosted on the same J2EE engine server where your development server is running.
And in some scenarios it is hosted on a completely different and isolated J2EE engine server.
Explanation begins here....
In CMS you define your Track. And with the track definition you have to define the runtime systems also.
NWDI leverages the 4 system landscape transport which suits your need perfectly without any doubt.
In your case you have...
DEV --> QTS --> MIRROR --> PRD
which is compatible with NWDI's
DEV -- > CONS --> TEST -- > PRD
Now, this simply means that you have no need at all for creating 2 different tracks, which is also suggested by expert John Wu.
So, this is what you have to do...
Edit the Runtime settings of your track.
For NWDI-DEV runtime system mention the Host Name and Deployment information of your DEV system.
For NWDI-CONS runtime system mention the Host Name and Deployment information of your QTS system.
For NWDI-TEST runtime system mention the Host Name and Deployment information of your MIRROR system.
For NWDI-PRD runtime system mention the Host Name and Deployment information of your PRD system.
But, but, but..Let me clarify you one very important thing here...
If you configure your track with above mentioned runtime system setting then this is what will happen...
Please make sure and confirm with your Technical Architect Expert whether this suggestion can be agreed or not.
Assume a real-time scenario....
You are modifying one DC in your NWDS and your activities are now checked-in from NWDS and now pending for activation.
1) When you trigger the Activate operation in NWDS then those DCs will be deployed along with the activity specific changes into your DEV (NWDI-DEV) system.
2) Now, the activities will be pending for Release under Transport view of NWDS. When you release those activities and Import them under Consolidation import successfully then it means that your DC along with those activity specific changes will now be deployed on your QTS (NWDI-CONS) system.
3) Now you have to complete the Assembly operation to generate the main single .SCA file that comprises all of the DCs present in a compiled form. Once the assembly operation is over you will see the same SCA waiting for import under your MIRROR (NWDI-TEST) system. Once the Import is successful then it represents now the complete SCA is deployed on the MIRROR system.
4) Now the SCA will be waiting for import queue of PRD system. Once the Import is successful here also then it means now your SCA was deployed on your PRD (NWDI-PRD) system.
Please refer to the below mentioned blog to get a clear and graphical picture of what i have explained...
:[Source Code Journey (NWDI under the Hood)|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/25521]
Please let me know about your findings and if you need any further inputs.
Regards,
Shreyas Pandya
Hi Pramod
We cannot configured 4 system landscape in one Track. Because Track always create 2 Build space.
Example - TRCDEV (Track Name)
DEV_TRCDEV_D (D - Development)
DEV_TRCDEV_C (C - Consolidate)
When create any activities and release then will move into DEV_TRCDEV_C ( Consolidate Build Space).
Let me know if am wrong and any better approach.
Hi Shreyas
Thanks. Same configuratiom i tried but Its not worked. When I release those activities and Import them under Consolidation import successfully. But not showing in out Test Server. which means activities shown in CBS under consolidate. but not in test system.
Let me know if am missing any thing.
Regards,
Ashish
Hi Pramod
>
> We cannot configured 4 system landscape in one Track. Because Track always create 2 Build space.
> Example - TRCDEV (Track Name)
>
> DEV_TRCDEV_D (D - Development)
> DEV_TRCDEV_C (C - Consolidate)
>
> When create any activities and release then will move into DEV_TRCDEV_C ( Consolidate Build Space).
>
>
> Let me know if am wrong and any better approach.
cannot understand here, what you mean?
configuring runtime system has nothing to do with buildspace
Hi ashishk78,
Can you please double check.
For NWDI-CONS runtime system you have mentioned the Host Name and Deployment information of your QTS system.
Because the when you import the activities into Consolidation it has to deploy those DCs along with the activity specific changes on the System that you have maintained in the CONS runtim System.
Perform the Assmbly step later and revert with your findings. whether those changes are getting deployed on the NWDI CONS (means your QTS) system or not?
Regards,
Shreyas Pandya
> Explanation begins here....
> In CMS you define your Track. And with the track definition you have to define the runtime systems also.
> NWDI leverages the 4 system landscape transport which suits your need perfectly without any doubt.
>
> In your case you have...
> DEV --> QTS --> MIRROR --> PRD
>
> which is compatible with NWDI's
> DEV -- > CONS --> TEST -- > PRD
>
If QTS is a QA system, it should not be defined under the CONS tab as it has not been assembled yet.
You ideally want the same assembled SC that has been tested in QA to be pushed to PRD.
You dont want to spend days or weeks testing something only to find out later you cant assemble it
and must make changes.
> Assume a real-time scenario....
> You are modifying one DC in your NWDS and your activities are now checked-in from NWDS and now pending for activation.
> 1) When you trigger the Activate operation in NWDS then those DCs will be deployed along with the activity specific changes into your DEV (NWDI-DEV) system.
This depends on how you setup the track's runtime system.Triggering the Activate option in NWDS will only deploy to the DEV system if the "Disable automatic deployment" option is not checked.
http://help.sap.com/saphelp_nw70/helpdata/EN/a0/43884445d6474eb103908f355bd558/content.htm
Yes Stefan is right. If we uncheck "Disable automatic deployment" then activities will import in Test (consolidate) system.
Again for Mirror & production, we need to release from NWDS and assemble then import manually.
But if checked "Disable automatic deployment" then activities will not deploy in test (consolidate).
Hi Stefan,
You have provided really nice inputs. I completely agree to all the points you have mentioned.
And Yes, I completely forgot to mention about "Disable automatic deployment" check box.
If it is checked in the scenario then it is of no use for ashishk78 to maintain it.
And I was aware about the QTS to be defined as CONS could be a little odd combination.
That is the reason why i have mentioned ashishk78 to consult with Technical Architect Expert whether this suggestion can be agreed or not.
Because, I fully agree that the final and a complete Unit of Transport that we call as .SCA, is generated only after the Assembly operation is completed.
If ashishk78 follows the same run-time system setting that i have mentioned then He has to be extra careful about changes that will be released and imported into Consolidation are consistent according to their delivery needs.
Let me Explain you in more details about under the hood process.
Assume you have imported a Track (TESTTRACK_dev) which contains only 2 DCs named DC_X and DC_Y.
So in NWDS you will see the Track as below...
- # TESTTRACK_dev[0]
+ ENGFACADE [sap.com]
+ ENGAPI [sap.com]
- SAMPLE_SC [test.com]
+ DC_X
+ DC_Y
+ FRAMEWORK [sap.com]
+ SAP_BUILDT [sap.com]
Now, here goes explanation about the difference between Assembled deployment and granular or scattered deployment...
SC Level deployment:
Assume that you have made modifications in your DC_X and later you have Checked-In, Activated, Released, Imported the activities into Consolidation and after Assembly you have imported the generated SAMPLE_SC.SCA into Quality system also.
In the above scenario Quality System will always receive the deployment in the form of SCA (The whole Unit of Transport).
Containing DC_X & DC_Y. It always considers the whole SC as a Unit of deployment and not the individual DCs.
DC Level deployment:
Now here if you assume that you have modified DC_Y and then straight away deployed the same DC_Y to Quality server from NWDS directly.
This way of deployment breaks the standards that are leveraged in Assembled or SCA deployment.
But still this deployment will over-right the same DC_Y packaged inside SAMPLE_SC.SCA which already present on Quality Sever. The only difference is that this deployment involved only DC_Y deployment instead of whole SCA unit.
And this is exactly what will happen for QTS - CONS combination, If ashishk78 follows the same run-time system setting that i have mentioned.
Regards,
Shreyas Pandya
>
> DC Level deployment:
> Now here if you assume that you have modified DC_Y and then straight away deployed the same DC_Y to Quality server from NWDS directly.
> This way of deployment breaks the standards that are leveraged in Assembled or SCA deployment.
> But still this deployment will over-right the same DC_Y packaged inside SAMPLE_SC.SCA which already present on Quality Sever. The only difference is that this deployment involved only DC_Y deployment instead of whole SCA unit.
>
> And this is exactly what will happen for QTS - CONS combination, If ashishk78 follows the same run-time system setting that i have mentioned.
>
With the QTS - CONS combination, the SAMPLE_SC.SCA will not be present on the Quality server as it has not been assembled yet. SAMPLE_SC.SCA only gets created in the Assembly tab. It will be present on the Quality server if the server is defined as a TEST or PRODUCTION system and only when the SCA has been imported into the TEST or PRODUCTION systems.
From [help.sap.com|http://help.sap.com/saphelp_nw70/Helpdata/en/ab/40833c87ac4d0cb5c4c44da8259386/frameset.htm]
You create software component archives in the assembly step of the Transport Studio. This step extracts the current state of the software in the DTR workspace of the consolidation system, gets the required archives from CBS, and uses these to assemble a uniquely defined state of the software component.
The assembly process packs the software component into an archive of type Software Component Archive (SCA).
Hi Stefan
Really great. So we are going with 2 track because we need to assemble any component before import in QAS, TST and PROD.
But still have issue, I have configured 2nd Track without DTR and CBS. After assemble and approve, requtest now showing in Track2 ' production queue.
Let me know, what am missing?
Hi Stefan
>
> Really great. So we are going with 2 track because we need to assemble any component before import in QAS, TST and PROD.
> But still have issue, I have configured 2nd Track without DTR and CBS. After assemble and approve, requtest now showing in Track2 ' production queue.
>
> Let me know, what am missing?
Assuming that track 1 has QAS defined as the Test runtime and TST is defined as the Production runtime and on track 2 PROD is defined as a Production runtime.
After you assemble the SC in track 1, it will appear in the Test tab of track 1. After importing the SC in the Test tab of track 1, it will appear in the Approval tab of track 1. Once you approve the SC in track 1, it will appear in both the Production tab of track 1 and in the Development tab of track 2. Once you import the SC in the Production tab of track 1, you can then import the SC in the Development, Approval and Production tabs of track 2.
Hi Stefan
After assemble the SC in track 1, it will appear in the Test tab of track 1. After importing the SC in the Test tab of track 1, it will appear in the Approval tab of track 1. Once you approve the SC in track 1, it will appear in both the Production tab of track 1 and in the Development tab of track 2. Thats fine.
But -
Once I import the SC in the Development tab of track 2, Developed software component will appear in assemble Tab for Track 2.
and other software component like ( SAP_BUILDT, MI_BUILDT, XMII) will direct appear in approval tab of Track 2.
If i try again to assemble the developoped software component in track 2 will showing error -
"Unexpected error; inform your system administrator: Illegal null value got: CmscdevconfPK version=0,name=null"
Please let me know whats wrong in track 2?
> Once I import the SC in the Development tab of track 2, Developed software component will appear in assemble Tab for Track 2.
> and other software component like ( SAP_BUILDT, MI_BUILDT, XMII) will direct appear in approval tab of Track 2.
> If i try again to assemble the developoped software component in track 2 will showing error -
>
> "Unexpected error; inform your system administrator: Illegal null value got: CmscdevconfPK version=0,name=null"
>
> Please let me know whats wrong in track 2?
The goal of this two track setup is to assemble the SC once and the same SC will be pushed to all the environments.
You did not setup track 2 correctly as you are not supposed to have an Assembly tab on track 2. Track 2 should only have the Check-in, Development, Approval, Production and System State tabs. Create a new track 2 following these [instructions|http://help.sap.com/saphelp_nw70/helpdata/en/42/f1a03611d83ee4e10000000a1553f7/content.htm].
You should not transport build plugins (eg SAP_BUILDT, MI_BUILDT) via the NWDI as they are not needed on the runtime system.
Hello
>
> Setting up a NWDI track connection for DEV,QTS, MIRROR and PRD systems.
>
> DEV, QTS and MIRROR - Track 1
>
> PRD - Track 2
>
> How to link the tracks (1 & 2) for transport sequence DEV,QTS, MIRROR & PRD
Setup a "transport" connection between Track 1 and Track 2
Follow the "Recommended Track Design for Ongoing Development" in Marion Schlotte's [blog|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3390]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Before create track connection. Some question -
>
> 1. Can i create Track 2 same as copy of Track 1?
> 2. Should be assign software component to track 2 or not?
> 3. when i approve software component from Track 1. So will appear in both track (Production tab) ?
1)No.You dont want DTR workspaces or build spaces in your PRD track
2) Follow what the blog says and adapt it to your needs.
3) Yes.
User | Count |
---|---|
87 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.