cancel
Showing results for 
Search instead for 
Did you mean: 

Solution Manager/Charm and Transport Dependency Check

former_member552974
Participant
0 Kudos

Hello Everyone,

I apologize if this question has an obvious answer. I have searched SDN and could not get a 100% answer.

We are just now in the process of rolling out Charm/Solution Manager and I have noticed that it appears to not perform transport dependency checks. For example, let's say I am working on object ABC and have completed my testing (ready for transport to production) and then another developer also starts development on object ABC. When my change is moved to production, it will pick up the other developers modifications without giving a warning or an error that a dependency has been encountered between the two transport requests.

Does Charm/Solution Manager offer the option of producing a warning should a transport depedency be identified? If so, will someone explain (or point me to the appropriate documentation) how this can be set up?

Best Regards,

Scott

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Scott,

ChaRM supports imports from DEV->QAS->PRD by transport by transport requests level not by transport request task level. So don't worry(i.e., You can't import only your change of object ABC to production. It allows to import your change and other user's change of object ABC together to production).

This is how it works(if more than an user works on the same object):

1. Requester creates a support message from satelitte system to report a problem.

2. Service desk employee creates a change document because some changes need to be done on object ABC to correct that reported problem.

3. Change Manager approves the change document. So a normal correction is created automatically.

4. This normal correction is assigned to 2 developers(your scenario) like for an example DVPR1 and DVPR2.

5. DVPR1 creates a transport request and does some changes on object ABC. So a transport task will be created for DVPR1 under that transport request automatically.

6. When DVPR2 tries to do some changes on the same object ABC, a seperate transport task(not a transport request) will be created for DVPR2 under the same transport request because the object ABC is locked under the transport request. So DVPR2 can't create a separate transport request for the same object if any transport request is pending(not released).

7. Now object ABC will have one transport request. That transport request will have 2 transport tasks(1 for DVPR1 and 1 for DVPR2).

8. Each developer relases their transport task only(not transport request) once he/she completes his/her change on the object ABC.

9. DVPR1 or DVPR2 will change the status of normal correction to "Development Completed".

10. Now, IT operator or DVPR1 or DVPR2 can release the transport request. The transport request can be released only if all tasks are released under the same transport request.

(In this example: DVPR1 completed his change and released his transport task. Next DVPR2 completed and released his transport task).

11. Finally IT operator import the transport request to QAS and PRD.

Hope you are clear now. Let me know if you have any doubts.

Regards,

Sanjai

former_member552974
Participant
0 Kudos

Hi Sanjai, All,

Thank you for the response. In the scenario that I am encountering, it would be where the same object is in two separate trasnport requests. Thus we may not have two tasks (one per developer) under one request. We actually could have two requests (one per developer). The dependency issue comes to surface when one developer is ready to move their change in, but the other developer is not ready. There appears to be no warning in the system that would let the first developer know that the object they are about to move in is also in another developers transport request.

Do you (or anyone else) know if there is a way to check dependencies in Charm prior to moving tranpsort request to production?

Best Regards,

Scott

raguraman_c
Active Contributor
0 Kudos

Hi Scott,

Sanjay has made it clear in his point 6.

>

6. When DVPR2 tries to do some changes on the same object ABC, a seperate transport task(not a transport request) will be created for DVPR2 under the same transport request because the object ABC is locked under the transport request. So DVPR2 can't create a separate transport request for the same object if any transport request is pending(not released).

If the TR for Object ABC is not released yet, when the second developer does some changes, the system will create a Task, not a Transport request.

Hope this helps.

Feel free to revert back.

-=-Ragu

Former Member
0 Kudos

Dear Sanjai

I think, that this is the matter of Change Request manager - if there is a project ABC to develop, you shoud have only one Change Request -> One created Transport Req -> one or more Transport Tasks. Is a new Change Req. appears, the Ch.R. Manager shoud not approve it. Or, is yes, he/she should be very avare of what is going on! This is more methodology thing than problem of ChRM.

Hope, this helps.

Petr