Contact First/Given Name: margaret
Question: I'd like to confirm these enumerated values:
Immediate - does this mean that requester is going to wait online until the results are ready (i.e. I'll wait until you process the credit check and have results to send back immediately)
Delayed - does this mean that I'm submitting my request for a credit check and the supplier just needs to respond with an acknowledgement that the order was recieved. Then the results will be sent back in a separate request/response transaction.
Margaret,
I assume you are talking about ScreeningOrderServiceCode. You probably found this definition: Refers to type of order processing pattern or level of service requested. This is an open HR-XML list. Enumerated values are Delayed and Immediate. Delayed = Acknowledgement of order receipt requested, but no immediate business-level processing expected. Immediate = Immediate business-level processing expected. This is an HR-XML Open List.
"Immediate" does imply a near-real-time response, which might support the return of a result to a user waiting for a result. I guess there are only a few types of screenings where this might be a reasonable expectation. **just an update to emphasize that this primarily is something that has meaning with a particular trading partner arrangement. I probably should just leave it there. I think the definition is actually pretty good -- immediate business-level processing. I think a synchronous, real time response with a result is a likely outcome, but the message exchange is really a separate matter.***
I'd agree that delayed is generally has the meaning you describe.
One point I should make is that these codes are intended to give trading partners information about a level of service they have worked out among themselves. While we have traditionally thought of web services as working in a request-response pattern, one of the items I expect to work on next year are some patterns using WS reliable messaging and WS addressing. I guess my point is that right now, those service level codes seem to imply a particular message exchange pattern. I think going forward we'll be able to handle things a bit more flexibly. I actually was just corresponding with the principal at IBM behind a program called WSTF.org They are specifically interested in our background check use cases since they present some characteristics that some of the reliable, ayschronus messaging approaches may be able to handle well. Consider that a single order might produce a near-real-time SSN trace or search of prior work result (Frank Smith's SSN is valid), error information (we need Frank Smith's Drivers License ID if you want to do an MVR), and kick off long-running processes that take days or weeks to complete.
I realize that this is likely much more than you likely were looking for, but we are interested in gathering some of the crazy synchronous and asynchronous use cases that background check services present.
--
Chuck Allen
