Transport sequences, normal change and java

[MrLuuL]

Hi

I have a problem with CHARM, transport sequences, normal change and java.

The scenario is we have a normal change with 2 transports, lets say TR:1 and TR:2.

TR:1 is already assembled (developed) in CMS and done, when we now assembled (developed) in CMS

and put it into TR:2 its creating a new transport of copys in the Normal Change for both TR:1 and TR:2 when we "Pass Normal Change to test".

The problem is that the TR:2 creates first in the import queue in TMS and then TR:1 when we "Pass Normal Change to test" on the normal change.

The developers have used same component(object) so when we import this we first get the new code(TR:2) imported and then we get the old code(TR:1) imported if we follow the import queue.

Why its behave like this?

Is it possible to decide which order its get released in TMS or whats decide the release rule to the import queue?

Is the solution to split this two transport into two normal changes?

How can i solve this problem?

We have latest and greatest support patch on solution manager.

Regards Ulf Lundqvist

[prakhar_saxena]

Hi Ulf

Yes it is possible to do selective import

Status-Dependent Import and Selective Import of Transport Requests

also for release strategy you can check my reply on below thread

Transport sequencing in ZMHF | SCN

let us know if you need more inputs.

thanks

Prakhar

[MrLuuL]

Hi Prakhar

Yes we have also setup the selective import in solution manager but we only use it in some cases.

We have a 4 landscape solution on SAP and between Dev and test we have a automatic job running "/TMWFLOW/SCHEDULE_IMPORT", between test -> acc->produktion we using TR:SCMA - Schedule Import Job for Transport Request, then we get the selective import list.

We are using the SAP0: SAP Delivery Variant for Task List in Task Plan in solar_project_admin - Change Management tab and its working fine.

The problem we have is when we change the normal change to Phase "Pass Normal Change to test" the CHARM adds to the buffer in a strange order. The most recent change is adding to the buffer first (TR:2) then (TR:1) with older objects and overwrites TR:2.

When we then running the job "/TMWFLOW/SCHEDULE_IMPORT" its imported in order TR:2, TR:1.

Charm log.

The CEDK90012O is second.

Transport Management order

The CEDK90012O is second.

STMS Queue history log

The CEDK90012O is first.

[prakhar_saxena]

Hi Ulf,

Its a bit difficult to help without system access in this case ...but i will try.

you can check between these 2 transport which one is released at what time in Se09 transaction of ur development system(managed system like ERP etc)

Typically the standard behaviour for ChaRM is all the TRs are imported in the order of their release.

so we need to check the release time for TR1 should be first and then TR2 should be released because if TR2 is released first then it will be imported first as its get added to Queue buffer first.

let me know if this helps

thanks

Prakhar

[MrLuuL]

Hi Prakhar

When i check this two java transport in the Normal change its look like this.

TR:1 = CEDK90012B

TR:2 = CEDK90012O

When I change the status of this Normal change to "Pass Normal Change to test" the import queue creates as follow.

This is not so good order because in TR:2 = CEDK90013F (copy of CEDK90012O) we have the last changes for xx.se~WEBDEPOT~NWD_PCE74P01_C~20150819093720.sca

This means that TR:1 = CEDK90013D (copy of CEDK90012B) going to overwrite TR:2 = CEDK90013F (copy of CEDK90012O) if I importing it in this order.

When I check the new transport of copies we get when we change the status to "Pass Normal Change to test", CEDK90013D and CEDK90013F they are looks like this.

TR:1 = CEDK90013D

TR:2 = CEDK90013F

If I going back to status “Reset Status to in Development” and change back to "Pass Normal Change to test" I get the same problem with the transport in “wrong” order.

This means that the problem is in CHARM somewhere, how it’s creating the transport of copies.

Is anyone know how charm calculate in which permission it’s creating the transport queue or release it order?

It’s not the trp number order, not CMS CREATIONTIME or PATCH NAME, what can it be?

Or is the solution that we can’t develop in same software_component if we have the transports in the same normal change?

Regards Ulf Lundqvist

[MrLuuL]

We have debug the functional module(TMW_CREATE_TRANSPORT_OF_COPIES) and then we gets the trp in right order when we doing it step by step.

I am going to open a case at SAP.

[MrLuuL]

This is how the transport of copies and java works.

When you change to Phase "Pass Normal Change to test" in the normal change its export the files to the TP command. I our case the TR:1 is bigger and take longer time to export so the TR:2 adds to the buffer before TR:1.

Charm (TMW_CREATE_TRANSPORT_OF_COPIES ) has no control over the import queue sequence, its sending it to the TP command in the background.

Because it work like this we are thinking over the situation how to find a work around.

• Never develop in the same software component in two different transport if they are in the same Normal change.
• Attach the software component in both transports so its the same.
• One transport = Normal Change.
• Not use CHARM for java.
• etcetra .....

The conclusion is that the developer still need to have the full control over which software component everybody have worked with.

Regards Ulf Lundqvist