Assignment Streaming
Using assignment streaming for better performance
Overview
With the introduction of assignment streaming, a new two phase call approach became necessary. The initial call will obtain summary information for open assignments, while details for those assignments are obtained via a secondary call to the API. One call per portfolio plus table type will be necessary to obtain the assignment details.
Deprecated API
Assignment streaming is a replacement to the previously existing calls:
All assignments
get
/v1.0/records/assignments
All assignments for one portfolio
get
/v1.0/{portfolioGuid:guid}/records/assignments
Assignment streaming API
Obtain assignment summaries for all portfolios
get
/v1.0/records/assignments/summaries
Obtain assignment summaries within a single portfolio
get
/v1.0/{portfolioGuid:guid}/records/assignments/summaries
Obtain assignment details within a given portfolio and table type
post
/v1.0/{portfolioGuid:guid}/records/assignments/details
{ "Guids": [ ... ], "TableType": ...}The original endpoint that returned all information in one response was on the one hand more convenient, but on the other hand subject to poor performance. It was decided to break up the processing into separate calls.
Using Assignment Streaming
You must first make a call to obtain summaries of open assignments with either v1.0/records/assignments/summaries or v1.0/{portfolioGuid}/records/assignments/summaries. Summaries contain basic information, and the most important pieces are the OrganizationId, TableType and Guid fields. The caller will need to use this information to build details calls.
Below are two samples of forming the calls and the responses you might get. The objects obtained from the details calls can be used as a replacement for the data received from the previously existing v1.0/records/assignments and v1.0/{portfolioGuid}/records/assignments calls.
Examples
Summary call response
GET: /v1.0/records/assignments/summaries
Sample response body:[ { "PortfolioId":"a0be0f91-83cf-43b2-bb42-2878ec39e324", // portfolio 1 "PortfolioName":"Portfolio 1", "ProjectId":3, "ProjectName":"Integration Tests", "TableType":8, "Guid":"f12c23d1-a4f6-4cf9-8660-569d91f9dcde", "DueDate":"" }, { "PortfolioId":"8eebc5c7-3d50-4166-8646-d49cf96fa54b", // portfolio 2 "PortfolioName":"Portfolio 2", "ProjectId":2, "ProjectName":"NewProject", "TableType":8, "Guid":"a5ad7bb5-495f-4c4c-90cf-79e49cd8d731", "DueDate":"" }]Details calls
Two different portfolios
POST: /v1.0/a0be0f91-83cf-43b2-bb42-2878ec39e324/records/assignments/details
Sample request body:{ "Guids": [ "f12c23d1-a4f6-4cf9-8660-569d91f9dcde" ], "TableType": 8}
Sample response body: // portfolio 1 details[ { "PortfolioId":"a0be0f91-83cf-43b2-bb42-2878ec39e324", "PortfolioName":"Portfolio 1", "ProjectId":3, "ProjectName":"Integration Tests", "TableType":8, "PrimaryKey":8, "Guid":"f12c23d1-a4f6-4cf9-8660-569d91f9dcde", "Summmary":"Test For Comment Section-ed7fac55b0", "WorkflowState":14, "WorkflowStateName":"Open", "DueDate":"2024-01-30" }]POST: /v1.0/8eebc5c7-3d50-4166-8646-d49cf96fa54b/records/assignments/details
Sample request body:{ "Guids": [ "a5ad7bb5-495f-4c4c-90cf-79e49cd8d731" ], "TableType": 8}
Sample response body: // portfolio 2 details[ { "PortfolioId":"8eebc5c7-3d50-4166-8646-d49cf96fa54b", "PortfolioName":"Portfolio 2", "ProjectId":3, "ProjectName":"NewProject", "TableType":8, "PrimaryKey":8, "Guid":"a5ad7bb5-495f-4c4c-90cf-79e49cd8d731", "Summmary":"Test For Comment Section-f73b6cd5a7", "WorkflowState":14, "WorkflowStateName":"Open", "DueDate":"2024-01-30" }]Parent/Child
Using Checklists
Checklists in ProjectSight rely on child records. For each checklist, there will be one or more checklist items. Each checklist item is a child of the parent checklist. The summary records returned will be one record per child record, while the records returned from the details calls will be one record per parent. Therefore there can be a different number of records returned between the two calls. The Guid returned for the items in the summary request will be for the child objects, whereas the Guid in the details object will be for the parent checklist.
In most cases the differences between the two responses will not matter, since you can use the results from the details calls as they are. The summary records only exist to give the caller a way to obtain the OrganizationId, TableType, and Guid fields with which to build the details request(s) object(s).
GET: v1.0/dbbb11ab-1d89-40a7-95b9-4ca88c078007/records/assignments/summaries
Response body:[ { "PortfolioId":"dbbb11ab-1d89-40a7-95b9-4ca88c078007", "PortfolioName":"BizLayerTests", "ProjectId":3, "ProjectName":"Integration Tests", "TableType":189, "Guid":"66ca814d-d332-4a5f-94c7-3b58ee9d9b64", "DueDate":"" }, { "PortfolioId":"dbbb11ab-1d89-40a7-95b9-4ca88c078007", "PortfolioName":"BizLayerTests", "ProjectId":3, "ProjectName":"Integration Tests", "TableType":189, "Guid":"b3489949-54ee-4f71-993b-de683f00ab8b", "DueDate":"" }]POST: /v1.0/dbbb11ab-1d89-40a7-95b9-4ca88c078007/records/assignments/details`
Sample request body:{ "Guids": [ "b3489949-54ee-4f71-993b-de683f00ab8b", "66ca814d-d332-4a5f-94c7-3b58ee9d9b64" ], "TableType": 189}
Sample response body:[ { "PortfolioId":"dbbb11ab-1d89-40a7-95b9-4ca88c078007", "PortfolioName":"BizLayerTests", "ProjectId":3, "ProjectName":"Integration Tests", "TableType":189, "PrimaryKey":1, "Guid":"1264bab5-e96c-40a4-a487-b7d9e806ccee", "Summmary":"Work Description-b1607a5f05", "WorkflowState":5, "WorkflowStateName":"Open", "DueDate":"0001-01-01", "ChildTableGuids": [ "b3489949-54ee-4f71-993b-de683f00ab8b" ] }, { "PortfolioId":"dbbb11ab-1d89-40a7-95b9-4ca88c078007", "PortfolioName":"BizLayerTests", "ProjectId":3, "ProjectName":"Integration Tests", "TableType":189, "PrimaryKey":2, "Guid":"23a1ca17-fb21-494f-9d28-0372cf3d08f5", "Summmary":"Work Description-31b47a551a", "WorkflowState":5, "WorkflowStateName":"Open", "DueDate":"0001-01-01", "ChildTableGuids":[ "66ca814d-d332-4a5f-94c7-3b58ee9d9b64"] }]