Sourcing refers to the procurement process where one party role (the provider) provides another party role (the receiver) with a catalogue. A catalogue is a document that describes items and prices.
The first thing to do is to differentiate server side role and client side role to achieve clean separation of concerns. A good hint for identifying the server side role is where the application data is located. In the case of sourcing, the party that plays the provider role owns the item data that is used to create the catalogues. Therefore it is straight-forward to implement the provider role as a service and make the receiver role a client.
As I learned today, UBL does not specify the actual procurement processes but merely provides the set of business documents to choose from when designing your own processes. This is nice, because it mens that UBL can be suitably applied even in the context of this little experiment.
As a first step, the provider role service will just provide a public catalogue, let’s say at http://labs.nordsc.com/procurement/roles/provider/common-catalogue.
Assuming the receiver role client discovered that URL from the service document describing the provider service the following HTTP interaction could take place for catalogue provisioning:
GET /procurement/roles/provider/common-catalogue Host: labs.nordsc.com Accept: application/vnd.nordsc.procurement+xml 200 Ok Content-Type: application/vnd.nordsc.procurement+xml Cache-Control: public,must-revalidate ETag: 1 <?xml version="1.0"?> <Catalogue xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2" "> <cbc:ID>public-001</cbc:ID> <cbc:IssueDate>2010-02-02</cbc:IssueDate> <cac:CatalogueLine> <cbc:ID>ID0</cbc:ID> <cac:Item/> </cac:CatalogueLine> </Catalogue>
The catalogue representation is only a stub at the moment, we’ll get to the media type issues later. Of particular interest is the caching policy for catalogues because the intention is for clients to use the latest catalogue data when placing an order. Catalogues can be potentially very large and we want them to be cached by public and private caches (Cache-Control: public) . However, since the freshness of the catalogue is very important, caches are instructed to never return a cached copy without prior revalidation (Cache-Control: must-revalidate).
Apart from the issue of the media type for the catalogue, we have now designed the most simple version of catalogue provisioning. It will be interesting to explore how other sourcing interactions (for example customer initiated sourcing) can later on be added.