Subject: Re: [scim] BulkId - how transient is it?

From: Kelly Grizzle <[email-masked]>
Date: Mon, 4 Feb 2013 21:42:30 +0000

This could get very tricky because you are dependent on ordering.  Consider the following:

1)      Client POSTs a new user (User A) which gets asynchronously processed.  A transient identifier is returned.

2)      Client performs a PUT or PATCH to update a different user (User B) and set User B's manager as User A.  This uses the transient identifier returned from request #1.

The problem is that request #2 may now need to be queued depending on whether request #1 has been completed.  It also raises your original question about how transient is the identifier.  If the identifier returned from request #1 is released after the async processing is complete, then request #2 could potentially be invalid.

With bulk, we added some constraints that make these non-issues.  It seems like it would be really hard to get this right for async identifiers.

--Kelly

From: Phil Hunt [mailto:[email-masked]]
Sent: Thursday, January 31, 2013 5:27 PM
To: Erik Wahlström
Cc: [email-masked] WG; Kelly Grizzle
Subject: Re: [scim] BulkId - how transient is it?

Erik,

Thanks for the links. The links you provided seem to cover a very different case than mine. In all the previous proposals, async processing seems to be about bulk requests with large numbers of operations that therefore might take a very long time to process.

In my case, a single transaction can spontaneously (e.g. by policy) turn into an async transaction.  For example, for a particular client, it may be policy that all new add requests go through an online approval workflow before being completed.

Or, a UI component modifies a user's email. But before that attribute can be set, policy requires the new value be confirmed. It's conceivable we could force the client to be "authoritative" and check the value itself. But it is really an example of the service provider's workflow taking final precedence (over the client's for example).

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-01-31, at 12:44 PM, Erik Wahlström wrote:

Yeah. It's, in it's current form, only valid in one request.
This where my 5 cents when we tried to get async into bulk. We opted out from it and settled for the limitations instead.

They include some pros and cons. Nothing fancy though.

The three alternatives we looked at:
https://code.google.com/p/scim/issues/attachmentText?id=11&aid=110005000&name=batch_0.1.txt&token=P_jxo114_stZ91x1fRZ39IQ93F8%3A1359663928990#287<https://code.google.com/p/scim/issues/attachmentText?id=11&aid=110005000&name=batch_0.1.txt&token=P_jxo114_stZ91x1fRZ39IQ93F8:1359663928990#287>

The final version before we removed it:
https://code.google.com/p/scim/issues/attachmentText?id=11&aid=110010000&name=bulk_0.6.txt&token=DZPyExCX4vkWBBmg_4pDigSS3TA%3A1359663928991#547<https://code.google.com/p/scim/issues/attachmentText?id=11&aid=110010000&name=bulk_0.6.txt&token=DZPyExCX4vkWBBmg_4pDigSS3TA:1359663928991#547>

/ Erik

On Jan 31, 2013, at 8:25 PM, Phil Hunt wrote:

To give some more background to the reason I'm asking. I'm considering what are the issues with ASYNC processing (where an operation does not complete immediately, eg. because of a workflow requirement). If we had asynchronous support, then it would create requirements (and conflicts) similar to bulk requests in that you have a series of transactions that may have to reference each other. For example, if someone POSTs a new User object and then wants to subsequently modify or reference that object prior to completion, than the same transient id issue comes up.

I'm looking for a way we could have a generalized simple solution. If the server returned status 202 (accepted) on the original POST, the URL returned could have qualities similar to bulkId.  This allows follow-on transactions/references to occur. Naturally, if the original POST fails, than as in Bulk, the dependent operations also fail.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote:

I believe that bulkId was intended to be scoped to a single request.  Erik, do you have any thoughts?

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, January 31, 2013 12:21 PM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [scim] BulkId - how transient is it?

Is bulkId intended to span multiple request/responses or is it intended only to be valid within a single bulk request?  In other words, if a bulk sequence of operations were split across 2 or more requests, could bulkId be valid?

>From the spec...

bulkId  The transient identifier of a newly created Resource,

         unique within a bulk request and created by the Consumer.  The

         bulkId serves as a surrogate Resource id enabling Consumers to

         uniquely identify newly created Resources in the Response and

         cross reference new Resources in and across operations within a

         bulk request.  REQUIRED when method is POST.

Thanks,

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim