Programmatically re-committing an object?

Help Developers
,
1

Hi :wave:

In Real-Time LCA we are doing lot of testing to make sure that data is being transferred and converted correctly in the different processes from Revit and all the way to RTLCA.

This requires me or the developers to have Revit installed, but I was curios to learn if it was possible to programmatically re-committing an object in through .NET?
This way our developer team could skip the Revit > Select > Send and instead commit directly to the server and take it from there?

/Martin

2

To put this differently, are you looking to have the same data trigger a webhook multiple times?

3

Hi @jonathon
Yes, effectively triggering a webhook with the “same” payload.

4

In which case this is easily achieved by either

  1. Receiving and storing the “Canonical” commit as a saved json- and then programmatically sending this data as the payload of a new commit.
  2. Same as 1. but without saving so receiving the commit data and sending happening on each trigger.

and the easiest:

  1. You may do this without receiving any commit data by specifying the canonical commit referencedObject on subsequent commits.

You specified .NET, but this can technically be done with any of the SDKs, including using REST.

For bonus points, you could perform this in Chrome Devtools.

5

Actually this was too easy to stop work without answering:

Using the GraphQL explorer (speckle.xyz/explorer)

If you know which commit you want to repeatedly send then you might already have the referencedObject ID

but if not you can first query the project stream to get this:

{
  project(id: "PROJECT_ID") {
    model(id: "MODEL_ID") {
      versions {
        items {
          createdAt
          message
          sourceApplication
          referencedObject
        }
      }
    }
  }
}

or in FE1 dialect

{
  stream(id: "0d73c92ad2") {
    branch(name: "base design") {
      commits {
        items {
          createdAt
          message
          sourceApplication
          referencedObject
        }
      }
    }
  }
}

This will list all the commits you’ve sent from Revit or whatever - I’ve included the date, message and sourceApplication for identification ease, but really you only need the referencedObject

with what you now have the rest is a doddle with the mutation:

mutation CommitCreate($commit: CommitCreateInput!) {
  commitCreate(commit: $commit)
}

and variables:

{
  "commit": {
    "branchName": "1d9044db2c",
    "message": "Fake Message",
    "streamId": "0d73c92ad2",
    "objectId": "e5262a6fb51540974e6d07ac60b7fe5c",
    "sourceApplication": "Martin's Commit Trigger"
  }
}

There isn’t yet a VersionCreate equivalent in the GraphQL API … yet

The sourceApplication is optional, but might help in identifying your fake commits in the logs.

2 Likes
6

Thanks @jonathon

I honestly didn’t know that you simply could re-commit an already applied referencedObject. Nice! That is gonna be very helpful for the dev team. :muscle::tada:

This made me think (yes, believe it or not :sweat_smile:)

Let’s say I want to have a script that creates a new stream, commits an existing referencedObject and invites people to that stream.

I just tried to reference another existing streamId but keeping the referencedObjectId, which obviously throughs an error since it’s not able to locate the referencedObject within that streamId.

How could I do this?
Storing the json object and sending that?

This would serve as a script we could run in an automatic flow for each new tenant we onboard, so they have the same Demo project but in different streams when they enter the platform ← which is done manually now :unamused:

7

In this case, you must retrieve the data and then send a ‘fresh’ commit. All versions are specific to a project and not a server.

In the onboarding of FE2 this is almost how the Sample project is created, it is a bit more database, but you could (or get someone else to) take a look at how this magic is performed but you can easily do it as you described.

If it is always the same sample project, then definitely store the JSON data. This is where using the SDKs is important useful as all objects that have nested referenced objects will need to be fully resolved in your stored JSON. It will then need to be serialised, sent to the server and then a commit made of that serialised data payload.

And I thought I had gotten to clock off today.