I got myself in a bit of a spin last week when I realised that teams implementing the SData global accounting & CRM contract had used differing URL structures. Basically at the contract URL level some teams had used “crmErp” as the contract identifier and some had used “gcrm” – even though they were implementing the same SData contract.
I also noticed after visiting a 3rd party developer who were developing an SData consumer application against the accounting & CRM contract they were “hard coding” the contract URL as “gcrm” – fine for the particular SData provider they were initially deploying against (Sage 50 UK – who used “gcrm” as the contract identifier) but a problem when their application was pointed to another SData provider (Sage Murano in Spain – who used “crmErp”).
Now obviously we shouldn’t be hard coding URL’s in our SData clients – we should all be using “intelligent endpoint management” – that is querying an SData provider for its list of endpoint URL’s and the dynamically building the correct URL’s based on what the provider has exposed. This is basic “discoverability” using the SData registry.
So in the example above the 3rd party developer would dynamically build URL’s with gcrm in the contract segment when working with Sage 50 and dynamically build URL’s with crmErp when working with Murano – both found by querying the list of available endpoints for each app in the SData registry. Thankfully the 3rd party were in a position to implement intelligent endpoint management.
So for anyone else setting off down the SData route the advice is this – query the SData registry of an application, find out the details of the endpoint URL’s made available by that application, and construct your RESTful SData requests using dynamically built URL’s.