2 followers Follow

Question: How to programmatically create dependencies between parallel tasks in a release?


I'm trying to model a release in XLR on one that is already configured in another third-party system. The tasks in the release do not have a strict sequential order, but rather they are coordinated by task inter-dependencies such that every task can start as soon as the tasks it depend on (if any) have completed. I can query this system for its task definitions, and from that data I'm creating XLR tasks with the REST API, all within the same parallel group.

From what I can tell, the appropriate way to configure dependencies between tasks is to use links. I'm able to create links in the Planner UI, but I don't see any method for creating them documented in the 4.7.x REST or Jython APIs. I eventually came across the PlanningResource documented in the 4.0.x REST API, and that seems to do what I want (I'm using XLR 4.7.1).

Here's an example to demonstrate what I'm doing.

Suppose you have the following parallel group PG with subtasks Task1 and Task2.

PG: Applications/Release9999999/Phase8888888/Task7777777
Task1: Applications/Release9999999/Phase8888888/Task7777777/Task1111111
Task2: Applications/Release9999999/Phase8888888/Task7777777/Task2222222

You'd like to create a link from Task1 to Task2 so that Task2 can begin as soon as Task1 is done. Submit this HTTP request to the XLR server.

HTTP method: POST
Authorization: Basic ((base64-encoded username:password))
Content-type: application/json

The response should come back with a status of 200 and this body:

I have three questions:
* Are links the best way to configure these kinds of task dependencies?
* Is the PlanningResource the appropriate way to programmatically create links?
* When using XLR 4.7.x, why don't the (internal?) resources listed in the 4.0.x REST API use the same CI ID format as the standard 4.7.x REST API?


Mason A. Cree Answered

Please sign in to leave a comment.

1 comment


Hi Mason

You got it right: Links are used to model task dependencies. They were exposed in 4.0 as part of "the API" which later became "the internal API". From XL Release 4.5 on we published the "Public API", which we will support and check for backwards compatibility. We will not do that with the internal API, it may change in the future (although in practice it is relatively stable)

One part of publishing the Public API was defining the CI ID format in a consistent way -- that is the way that will be used in the future of the Public API. The old API did some transformations to make life easier in the front end but that wouldn't make sense in a stand-alone Rest API.

We will keep in mind that you are using the internal API to make links and hop e to expose that in the Public API in the future.

Hes Siemelink 1 vote