Ir para o conteúdo

Upgrade to FieldTwin 8

This major release version introduces an entirely new backend architecture and database for the FieldTwin platform that is purely event stream driven. These changes in architecture allows us to offer better Change Management Control for projects and workflows, project versioning and audit trails as well as project time travel capabilities. In addition you will now experience greatly improved project loading and rendering speed by a factor of 7-10x.

7.x to 8.0 API changes

In the 8.0 release we introduced a new backend architecture that allows projects to be branched and merged using git style workflows. In order to support multiple branches of one project we have introduced a new ID named streamId in the API and in window messages and the JWT.

To keep the window messages and API v1.9 compatible with this change, the subproject ID in 8.0 is now composed of 2 parts: subProjectId:streamId, however the API will continue to accept the older form of subProjectId as well.

Content of JWT in 7.1:

{
  "userEmail": "matt@futureon.com",
  "accountId": "-MIyPbG_cjUjO7E3ZgzZ",
  "projectId": "-M-HHqMifhz6qskW2goc",
  "subProjectId": "-NlT9gazCfieinkJYsOv",
}

Content of JWT in 8.0:

{
  "userEmail": "matt@futureon.com",
  "accountId": "-MIyPbG_cjUjO7E3ZgzZ",
  "projectId": "-M-HHqMifhz6qskW2goc",
  "subProjectId": "-NlT9gazCfieinkJYsOv:-NlT9gbQQVEiFVxlL2_U",
  "streamId": "-NlT9gbQQVEiFVxlL2_U",
}

Since the API accepts either subProjectId or subProjectId:streamId, existing code that calls the API using jwt.subProjectId or window message message.subProject should continue to work unchanged.

Compatibility issues

  • If you use the subproject ID as a key to find other records you will need to make this change to convert the ID to the legacy value:
subProjectId = subProjectId.split(':')[0]
  • In FieldTwin 8.1 and beyond, if it is appropriate to store your data at branch level, use the full subProjectId:streamId or incorporate the new streamId separately
  • API v1.8 and below has been removed
  • The JWT userRights now includes canViewDocuments and canEditDocuments and the API now enforces them
  • Invalid layers (e.g. unsupported files) in a subproject used to be ignored. To avoid ambiguous data, failure to load a layer now causes all API calls for that subproject to return an error.
  • To fix this: open the subproject in Design, view the Layers in the Project View tab, find the layers that have a red warning triangle and delete them