Open APIs

Hi Team, 

We are planning to use TMF655 for change request management. In our scenario a single change request can contain multiple tasks and these tasks can be executed by different teams.
Can you help to link the task and the team who would execute that task to have clear indication of task and team to which it is assigned.

relatedParty is available under change request, but option to link relatedParty with Task is not available.

Scenario-
CR1
-Task1 - To be executed by relatedParty1
-Task2 - To be executed by relatedParty2
-Task3 - To be executed by relatedParty1

Hi Kanchan

I'm not so familiar with the change request API, but it does seem that you have a point. I'll add that the Task schema is very naive, and perhaps it should be replaced by the TaskFlow schema, used also in the Process Management API. We really shouldn't have multiple entities that have the same semantic meaning.

TaskFlow does indeed include a list of related parties, which is exactly what you are looking for.

I just don't know who is maintaining this API, and if it is feasible to make such a change. But I'll open a change request on the change request API ...

Hi Team, 

We are planning to use TMF655 for change request management. In our scenario a single change request can contain multiple tasks and these tasks can be executed by different teams.
Can you help to link the task and the team who would execute that task to have clear indication of task and team to which it is assigned.

relatedParty is available under change request, but option to link relatedParty with Task is not available.

Scenario-
CR1
-Task1 - To be executed by relatedParty1
-Task2 - To be executed by relatedParty2
-Task3 - To be executed by relatedParty1

I haven't looked at TMF655 before this however I see that it does, as I assumed, implement the Entity Relationship pattern as most APIs do:

{
    "description": "Containing Change Request",
    "@type": "ChangeRequest",
    "changeRequestRelationship": [
        {
            "relationshipType": "contained",
            "changeRequest": {
                "description": "Contained Change Request 1",
                "@type": "ChangeRequest",
                "relatedParty": {
                    ...
                },
                ...
        },
        {
            "relationshipType": "contained",
            "changeRequest": {
                "description": "Contained Change Request 2",
                "@type": "ChangeRequest",
                "relatedParty": {
                    ...
                },
                ...
        }
    ],
    ...
}

Hi Kanchan

I'm not so familiar with the change request API, but it does seem that you have a point. I'll add that the Task schema is very naive, and perhaps it should be replaced by the TaskFlow schema, used also in the Process Management API. We really shouldn't have multiple entities that have the same semantic meaning.

TaskFlow does indeed include a list of related parties, which is exactly what you are looking for.

I just don't know who is maintaining this API, and if it is feasible to make such a change. But I'll open a change request on the change request API ...

Hi Team, 

We are planning to use TMF655 for change request management. In our scenario a single change request can contain multiple tasks and these tasks can be executed by different teams.
Can you help to link the task and the team who would execute that task to have clear indication of task and team to which it is assigned.

relatedParty is available under change request, but option to link relatedParty with Task is not available.

Scenario-
CR1
-Task1 - To be executed by relatedParty1
-Task2 - To be executed by relatedParty2
-Task3 - To be executed by relatedParty1

Hi Kanchan

I'm not so familiar with the change request API, but it does seem that you have a point. I'll add that the Task schema is very naive, and perhaps it should be replaced by the TaskFlow schema, used also in the Process Management API. We really shouldn't have multiple entities that have the same semantic meaning.

TaskFlow does indeed include a list of related parties, which is exactly what you are looking for.

I just don't know who is maintaining this API, and if it is feasible to make such a change. But I'll open a change request on the change request API ...

Hi Team, 

We are planning to use TMF655 for change request management. In our scenario a single change request can contain multiple tasks and these tasks can be executed by different teams.
Can you help to link the task and the team who would execute that task to have clear indication of task and team to which it is assigned.

relatedParty is available under change request, but option to link relatedParty with Task is not available.

Scenario-
CR1
-Task1 - To be executed by relatedParty1
-Task2 - To be executed by relatedParty2
-Task3 - To be executed by relatedParty1

Thank you Jonathan for the feedback and opening the change request. In meantime, we will use Entity Relationship pattern as suggested by Vance below.

Hi Kanchan

I'm not so familiar with the change request API, but it does seem that you have a point. I'll add that the Task schema is very naive, and perhaps it should be replaced by the TaskFlow schema, used also in the Process Management API. We really shouldn't have multiple entities that have the same semantic meaning.

TaskFlow does indeed include a list of related parties, which is exactly what you are looking for.

I just don't know who is maintaining this API, and if it is feasible to make such a change. But I'll open a change request on the change request API ...

Hi Team, 

We are planning to use TMF655 for change request management. In our scenario a single change request can contain multiple tasks and these tasks can be executed by different teams.
Can you help to link the task and the team who would execute that task to have clear indication of task and team to which it is assigned.

relatedParty is available under change request, but option to link relatedParty with Task is not available.

Scenario-
CR1
-Task1 - To be executed by relatedParty1
-Task2 - To be executed by relatedParty2
-Task3 - To be executed by relatedParty1