Track connections

[Former Member]

Hi,

I've seen that there are two types of connections: transport and repair. Normally, developments are made over a track with the four standard environments: development, consolidation, test and production.

From development to consolidation, change request are represented by activities (i.e. I have a file-level granularity). From consolidation to production, change request are represented by SCA snapshots (i.e. I have a SC-level granularity: if I decide to take the changes to the next environment I have to take all the SC).

What I'd like to have is to defer the creation of the SCA at the time of the import into the production environment, in order to keep the file-level granularity that activities have (so even in the test environment, I don't have SCA files but I have activities).

I thought of achieving this by making two tracks: the first with only development and consolidation stages linked to the development and consolidation servers, respectively; the second with only development and production stages linked to the test and production servers, respectively.

Now what I need is a way to import activites from track 1 into track 2. If I'm not mistaken the repair connection should transport activities (instead the transport connection should transport whole SCAs).

Has someone ever tried this or does know if this is feasible?
Is there a way to see, in a SAP demo or blog, what I get in the transport studio when a track connection is used (transport or repair)?

Thank you,
Pietro

[Former Member]

Hi,
I have a couple more questions about tracks.

We currently have a track with all the environments enabled: Development, Consolidation, Test and Production. Our landscape is configured as follows:

• DEV: SDM deployment, Automatic deploy disabled, Runtime system not integrated in JSPM scenario
• CONS: Deploy controller deployment, Automatic deploy enabled, Runtime system integrated in JSPM scenario
• TEST, PROD: Deploy controller deployment, Runtime system integrated in JSPM scenario

When we need to transport a change, we close, activate and then release the activity with NWDS. After the activity is released, it appears in the Consolidation tab on the transport studio.

1) The fact that the Development tab is 'skipped' is because we do the close/activate/release activity from the NWDS?

Let's suppose I change the landscape as I've depicted before, with two tracks instead of one configured as follows:

1. DEV (old development), CONS (old consolidation)
2. DEV (old test), CONS (additional test), PROD (old production)

The tracks are connected via a repair connection from 1 to 2. Developers have the NWDS environment set up to work on the 1-DEV.

2) When an activity from Track-1 is transported into Track-2? When it is  closed, activated and released via NWDI or when it is imported into 1-CONS?

3) Where that activity will appear in Track-2 in the Transport Studio? In the "Check-in" or in the "Development" tab?

4) In order to see the changes deployed on 2-DEV what will be need to do? Just the Check-In (if the activity appears in the "Check-in" tab) or the Import (if the activity appears in the "Development" tab)?

Thank you,

Pietro

[dao_ha]

Hi Pietro,

If I'm not mistaken,

1. That's how it's supposed to work: when you release a selected activity (from NWDS), it is packed into a change request and placed in the import queue of the consolidation system. It'll only show up in the Dev tab if you check-in an external SCA (e.g. SAP SCAs downloaded from sapnet) from the Check-in tab or it was transported from another track.

2 & 3. As Jun mentioned before, when the activity is released into 1-CONS, it'll automatically show up in 2-DEV.

4. It's an import; i.e. in the 'Development' tab.

Hope it helps.

Dao

[Former Member]

Hi Dao,
thank you for your support (also a thank you to Jun).

Just to be sure: when you say

2 & 3. As Jun mentioned before, when the activity is released into 1-CONS, it'll automatically show up in 2-DEV.

You mean when I click "Import" in 1-DEV ("Development" tab) or when I click "Import" in 1-CONS ("Consolidation" tab)?

In the "new landscape setup" I have also to design an emergency rollback procedure for the production environment that should work as follows: when I import a SCA into production, if something goes wrong, I need to "overwrite" the last imported SCA with the last known working SCA (so the penultimate that was imported into production). I thought of creating a third track as follows:

     3. PROD (linked to the same server of 2-PROD)

There is a Transport connection between Track-2 and Track-3.
If things works as I intended, this is what should happen:

• Track-3 has only the "Check-In", "Approval" and "Production" tabs
• Whenever a SCA is imported into 2-PROD (click on "Import" in 2-PROD "Production" tab) it should appear on the "Check-In" tab of Track-3
• The SCA is checked-in by clicking on "Check-In". The SCA is shown in the "Approval" tab.
• If things goes well, I remove the SCA by clicking on "Reject"
• If things goes wrong and an emergency rollback is needed, I click on "Accept" (the SCA is shown in the "Production" tab) and then on "Import" ("Production" tab) to restore the previous system state.

Could it work or there could be problems (for example with SCA versioning or something like that)? Is there perhaps a smarter way to achieve this "Emergency rollback"?

Thank you for your patience, I greatly appreciate your help.
Pietro

[junwu]

why you make things so complicated?

do you think your team are able to follow your?

if you want to design some advanced scenario, you should find someone who know nwdi.

[Former Member]

Jun,

I'm asking these questions because I was trying to understand how track connections work and at the same time figure out a proposal on how to reorganize things in our landscape in a more efficient way.

If you have a smarter/simpler way to accomplish what I'm trying to achieve or if you have some advice that you could give me, I'll listen with pleasure. You can imagine that if I'm asking things here I don't have an NWDI expert at hand that I could use to clear my doubts.

Pietro

[junwu]

as you said you have no expert there, and you want to do some challenging stuff, it is a BIG risk.

initially you have only one track for development let's say trackA.

after project finished, the sca goes to prd server. meanwhile you should create trackB for maintenance.

trackA will connect to trackB via transport connection.

you can continue your development in trackA, trackB will always have the same code which is running in PRD server. so it can be used as emergency rollback. anyway its true purpose is for bug fix in prd.

you can always have the working sca to rescue your prd, which is store in achieve, you don't have to setup a track for that.

normally things will work like this.

regarding your customer's abnormal requirement

let's two features to be developed.

if they are totally independent, i think your design of third track with repair connection should work.

if not, i don't think nwdi will be able to manage that.

[Former Member]

Hi Jun,
thank you for your reply.

Jun Wu wrote:
regarding your customer's abnormal requirement
let's two features to be developed.
if they are totally independent, i think your design of third track with repair connection should work.
if not, i don't think nwdi will be able to manage that.

It was a Transport Connection not a Repair Connection the one that I wanted to make between Track-2 and Track-3. So the whole SCA is transported into Track-3, not the single activities.

Do you think that it still should work?

Thank you,
Pietro

[junwu]

the track sequence i described is not the same as yours.

trackA track1

trackB track3

trackC track2

as i said no additional track needed for emergency recovery

[dao_ha]

Hi Pietro,

I totally agree with Jun on this: you're running a BIG risk by trying to design some complicated thing you do not quite understand. If your NWDI is managed by an 'external group of people' and you have no NWDI expert on-site then, do yourself a favor by sitting down with this 'external group of people' (which, I expect, includes an NWDI expert) and making plans. Afterall, they'll be the ones who maintain your NWDI; if they have no idea what you're talking about or do not agree with your design then you DO have a problem 🙂

For 'emergency rollback', what's wrong with using history?

Cheers,

Dao

P.S. Also, please consult this well-known blog from Marion S.

http://scn.sap.com/people/marion.schlotte/blog/2006/03/30/best-practices-for-nwdi-track-design-for-o...

[junwu]

don't know why you want that. seems only to complicate yourself.

you talked a lot about "activity".

maybe you can have a look at nwdi of ce7.2 and nw7.3, which support activity based transport.

i haven't used that, only read some doc, don't know if that will satisfy you.

[Former Member]

Unfortunately, I'm stuck with 7.0 (2004s). No chance to get an upgrade to 7.2 or 7.3.

This is why I need to have activities even in test:
We have our projects inside a single SC. Let's suppose that our client wants two different enhancements to the application: EA, EB.

Let's suppose that EA goes in consolidation, and after some tests, EA is taken into the test environment. So a SCA file with EA is made.

Then EB goes in consolidation and a SCA file with EB and EA is made.

Our client verifies both enhancements at the same time in the Test environment. He tells us that EB is ok and has to go into production while EA need some bugfixing. Since I have SCA files, I cannot do that, because if I import the EB SCA file before EA SCA file, even the EA edits will be transported into production.

See you,
Pietro

[junwu]

within my knowledge, your notion should work.

[dao_ha]

Hi Pietro,

As an alternative to your needs (without having to create another track), how about you keep track of the history at various stages (Dev, Cons, Assembly, Test, ...) and go back to one of these earlier versions as needed? There are also the option to 'Export SCA' at different stages which you can re-import into the Dev (though I've never used these so I can't tell how they'll turn out to be).

In any case, unless you keep the source code (activities) of EA & EB separately, I think it'd be a bit tricky to achieve what you need. i.e. I guess you'd need to have versions of original+EA only, original+EB only, original+EA+EB, etc. to be used as needed.

Dao

[Former Member]

Hi Dao,

unfortunately using history does not solve the problem because at the moment that I transport my activities into consolidation they are stuck in a sequence (like a FIFO stack) and I cannot decide to transport any of them indipendently to the other environments even if the different activities are not interdependent (i.e. they're not about the same DCs).

Do you know if there's a way to have some kind of "official" confirmation that my 2-track scenario could work? Maybe from someone from SAP itself? Or something from the official documentation (which I haven't been able to find)?

Unfortunately our landscape is managed by an external group of people and I don't have any way to "get my hands dirty" and make tests.

Thank you,
Pietro

[dao_ha]

Hi Pietro,

Sorry, I can't help you there with neither an 'official' confirmation nor a way to get your hands 'dirty' 🙂

I guess you can always keep multiple versions of your source code in your NWDS, at least?

Cheers,

Dao

[Former Member]

Hi Dao,

well I'd need to try it to see if my idea works in practice. Unfortunately I cannot make "experiments" without formally asking the external company that manages our CMS landscape to set up some test servers and this is unfeasible without some preliminary evidence that this setup could work.

Is there a way at least to see what I get in the Transport Studio when a track connection is used (transport or repair)? E.g. : I use a repair connection from TrackA-Consolidation to TrackB-Development, so whenever I import an activity in TrA-Consolidation I see the same activity in the TrB-Development or TrB-Check-In.

Thank you,

Pietro

[junwu]

after you activate and release the activity in track A, it will be shown in the import list of dev of track b

[dao_ha]

Hi Pietro,

I'm not sure if what you'd like to have can be done. Since QA and Prod environments are not source code locations (hence, the transports of SCAs), I don't think you can (or you'd want to) 'defer the creation of the SCA at the time of the import into the production environment'. Same thing with the QA enviroment since it's supposed to simulate the Prod environment as close as possible. I figure you'd not want to have your source code in QA or Prod 🙂

The repair connection in NWDI is used for back transport as needed. Yes, you can have 2 tracks connected by a repair connection for maintenance purposes. Please refer to this link for more info

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/13/602b27f6fb41b4a9eb4f72eabb9832/frameset.htm

Hope it helps.

Dao

[Former Member]

Dao,

I asked a way to do that because I need it.
It's a long story to explain why I need to keep activities in the development/consolidation/test environments.

So: can I use the repair or transport track connection to forward-transport activities from the 1st Track (Development, Consolidation) to the 2nd Track (Test, Production) in order that as soon as I import them in consolidation they are ready to be imported in the Test environment?

Bear in mind that the "Test" in the 2nd Track will be configured as if it were a Development Environment. So the 1st Track is Dev, Cons. The 2nd Track is "Test" as Dev, Prod.

[dao_ha]

Hi Pietro,

Check the 'Track Connections' link sent in my previous post and follow the link to 'Back Transports in NWDI', you'll see a figure for back transport connections.  Using this figure, for your purpose, I guess you can try to make your track #1 the 'Maintenance' track (Dev -> Cons) with a 'Repair' track connection to track #2 the 'Development' track (QA (which acts as Dev) -> Prod). There'll be no connection from 'Development' track to 'Maintenance' track. I think that might meet your requirements.

I don't know which version of NWDI you have. As Jun mentioned, you'd probably want to check out more recent releases of NWDI for advanced features/capabilities.

Hope it helps.

Dao