There are mainly two ways to fetch data from PDS:
· OData URI conventions and Query Options (GET)
· Service Operations (POST)
OData protocol greatly simplifies fetching data over the web (http). We can use any web browser (or other free third party tools) to fetch OData data directly. Various URI conventions (and Query Options) supported by OData protocol gives us more flexibility in fetching/filtering data.
A .NET client application (consumer) would usually have a service reference to PDS in order to consume the service (similar to web reference to consume web services). When a service reference is created for a .NET consumer, it automatically creates proxy classes for all entities designed using the Personify WSD.
We can also use LINQ queries to fetch data from PDS using a .NET client application. However, every LINQ expression (used at client) is translated to respective OData URI convention before making a request to service. Simply put, the service understands only OData URI conventions and not LINQ.
The following are the OData query options supported by PDS:
· $metadata
· $filter (with "startswith" and "substringof" function support)
· $select
The following are the OData operators supported by PDS (to use with $filter):
· eq – Equals
· lt – Less than
· le – Less than or equal
· gt – Greater than
· ge – Greater than or equal
· ne – Not Equal to
· AND
· OR
· grouping using parenthesis
· "null" keywords with "eq" and "ne" operators
If
you are using a .NET client as the consumer and trying to fetch data from
PDS using LINQ, enough care should be taken to ensure that the OData URI
(generated/emitted by LINQ to the service) contains only the operators/options
from the above list. If you use operators/options other than the
above, you may experience unexpected results (or even errors). We support
fetching data with both secured (default) and anonymous ways (as described
in Anonymous Data Services
section)
If you are using IE, you may have to turn off “feed reading view”, as shown below:
EQUAL – Get all application codes for subsystem ORD
NOT EQUAL and OR – Get all communications of Do Not Call Flag Not Equal to true or type PHONE
LESST THAN OR EQUAL, GREATER THAN OR EQUAL and AND – Get all customer addresses in USA and postal code between 20000 and 30000
LESS THAN and GREATER THAN – Get all addresses with latitude greater than 38.81 and less than 38.99
“startswith” and “substringof”
http://localhost/PersonifyDataServices/PersonifyData.svc/CusActivities?$filter=startswith(CallTypeCode,%20'PHONE')
http://localhost/PersonifyDataServices/PersonifyData.svc/CusActivities?$filter=substringof('-IN',%20CallTypeCode)
http://localhost/PersonifyDataServices/PersonifyData.svc/CusActivities?$filter=(StaffUserId%20eq'POLAND'%20and%20ActivityDate%20gt%20datetime'2007-03 01'%20and%20startswith(ActivityText,%20'called'))
GROUPING – Get all customers information with last name SMITH and First Name ADRIAN or Customer ID 000000000009
SUB COLLECTION – Get Primary Address information for customer 000000000737
Note:
1. You cannot
use more than one filter item for Cached entities – Example: the following
throws an exception:
http://localhost/PersonifyDataServicesBase/PersonifyData.svc/ApplicationCodes?$filter=SubsystemString%20eq%20'ORD'%20and%20Type%20eq%20'PAY_FREQUENCY'
2. Operator
is always taken as EQUAL for Cached entities – Example: the following
always returns application codes for subsystem ORD:
http://localhost/PersonifyDataServicesBase/PersonifyData.svc/ApplicationCodes?$filter=SubsystemString%20ne%20'ORD'
The process of consuming OData service (using options mentioned in previous section) using .NET is a straight forward subject from MSDN. The following websites can provide more information:
http://msdn.microsoft.com/library/cc668792.aspx
http://msdn.microsoft.com/en-us/library/cc668772.aspx
http://msdn.microsoft.com/en-us/data/bb931106
http://coolthingoftheday.blogspot.com/2009/12/odata-my-linqpad-linqpad-beta-now.html
If
you are using ASP.NET, the “LinqDataSource” control can do most of the
fetching easily and is great for data binding ASP.NET controls. To
practice LINQ (with OData), LINQPad is a useful tool.
While OData protocol helps to simplify data fetch operations, it may not fit all business requirements. Perhaps you want to flatten out properties from several different collections and compute some statistics out of those. That may need lot of complicated processing behind the scenes and OData may not be appropriate. In such situations, you can create Service Operations to fetch data, but again, it would be a POST operation.
A POST operation usually sends a request to a service with lots of information including (but not limited to) the following:
· Consumer (browser/tool/application) information
· Content (data to be sent to service. In our case, it is going to be XML)
· Headers
· Authentication Information
· Service URL/URI
· Consumer’s Language/Date/Time
Fetching data using Service Operation can be accomplished by simply executing the same.