Page Comparison

...

• A client can determine the number of connections to all of their organization’s streams by using the GetStreams call or isolating to just one stream by using the GetStreams By ID call. In both of those calls a count of ‘members’ will be returned. The member count is the number of connections to that stream at the time the call was made. If there are 0 members/connections then you are not ingesting data from the stream at that time.

  • Remember when testing that putting opening a mainstream main stream URL in a browser tab will count as a connection and will engage load balancing. Placing mainstream main stream URLs in browser tabs is not recommended.

  • As noted above, “member” is the number of connections to that stream. It is not related to the number of users or patients in the org.

What SSE (Server Sent Events) listener should we use to ingest from Streaming API?

...

• This element of the Streaming API documentation should be reviewed.

• The id in the data event will persist for each update that comes through for that record.

• The checksum will be unique for each update to a data event id

• The client should have logic to check if the id was previously processed. If so, then you have an update to that data event coming through. The client should write the values for the most recent checksum for a given id to their database. The most recent can be determined by the created_at in the data event payload.

• This is most commonly seen with Summary records as they are updated throughout the entire day, but can be seen with other data types. It is expected behavior to see updates for records days after the day of. This is due to user behavior that can be explained in this doc for cloud and this doc for SDK.

What happens if we create 2 main streams for the same org?

...