Section | ||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
About
The Pull Model is a way for Integration Partners to request records that are new or updated. This model is useful in a scenario where the usual real-time API calls are not possible.
Process
The Integration Partner initiates a "pull" from the Connector. Sample URL is:
Code Block <URL>/connector/api/2011-11/missingusers?provider=ACME&clientID=123456&clubID=9876
- provider (e.g. ACME) is the InTouch given ID of your system
- clientID (e.g. 123456) is the ID of the client. This is the top level entity. Also known as an enterprise, account, organization, customer. A client can have many clubs within it.
- clubID (e.g. 9876) is the ID of the specific club for this data. This is the physical health club with a real street address, etc...
- Note that the clientID and clubID may be any type of identifier: text, number, etc..
- This will return a list of ALL users in the Connector database that meet one of two conditions
- The Connector does not have a user ID for that user and provider (i.e. new user in InTouch which was sent to the Connector, but no user ID yet for the ACME provider)
- The record has been modified since the last time the provider fetched (and sync'ed) the user (i.e. updated user in InTouch which was sent to the Connector, so the modified timestamp is newer than the modified timestamp of the last callback for ACME for that user)
- Note this list is limited to 50 records, last in first out. Important: It is imperative that this list of returned records is not left so that it grows and grows as this could mean that some data gets orphaned from the web service.
- How the Integration Partner handles the returned data is up to them. What MUST happen is a callback to the Connector which is an acknowledgement that "I've sync'ed this user". A sample web service call here is a POST to <URL>/connector/api/2011-11/user/callback with the ID from the system making the pull (example below)
- After this callback is made, the user will not appear in the pull call again (unless the user is updated again in InTouch)
Examples
Example Pull Response
Code Block | ||||
---|---|---|---|---|
| ||||
<user> <userInfo> <connectorUUID>ce507497-992c-4eb8-bc7e-b0d46e7aa53f</connectorUUID> <createdBy>INTOUCH</createdBy> <createdDate>2012-06-28T18:26:29.101Z</createdDate> <modifiedBy>INTOUCH</modifiedBy> <modifiedDate>2012-07-03T23:55:49.937Z</modifiedDate> <firstname>John</firstname> <lastname>Doe</lastname> <userStatus>ACTIVE</userStatus> <userType>PROSPECT</userType> <address1/> <city/> <zipcode/> <country>US</country> <mobile>(555) 555-5555</mobile> <email>jdoe@email.com</email> <homePhone/> <workPhone>(213) 688-1441</workPhone> <company/> </userInfo> <userInfo> snip... repeat userInfo segments here </userInfo> </user> |
Callback Example
Code Block | ||||
---|---|---|---|---|
| ||||
<user> <providerInfo> <identifier>ACME</identifier> <clientID>123456</clientID> <clubID>9876</clubID> <recordID>1001</recordID> </providerInfo> <userInfo> <connectorUUID>ce507497-992c-4eb8-bc7e-b0d46e7aa53f</connectorUUID> </userInfo> </user> |