Connector OData

1. Connecting to WebApi

After creating a new Visual Studio project we have to install OData Connected Service – a tool that generates code based on our service description. We can find it via Tools -> Extensions and Updates by searching for „odata” keyword in „Online” tab, or here:


Once OData Connected Service is installed, we can proceed to adding Service Reference for our WebApi. We can achieve that by right-clicking on our project, and going into Add -> Connected Service. All things can be set to their default values, except Address. Set your metadata location and click „Finish”.


If everything was set up correctly, Service Reference will be added and Reference.cs file should contain code for all the classes.


 2.   Using OData Client.

First of all, lets reference our Odata Client and System.Security.Cryptography which we will need for authorization purposes.


After that we will need Public and Secret Keys for our WebApi, which can be found in the plugin configuration menu in admin panel. Once we have it, lets prepare our project for some examples.

Whole communication with WebApi is based on container. It requires Uri of our service root to be passed as an argument of its constructor. Apart from that, every request requires authentication headers attached to it or it won’t pass successfully. We achieve it by adding an event handler for our container, to automatically add appropriate headers whenever request is being built.


That puts an end to preparations, let’s proceed to examples. We will focus on Products and Categories as they are the most popular and important ones, hence the easiest to explain. We access every entity via container, being able to perform multiple actions i.a. Filter, Skip or Take. Some types might come in two versions, for instance Product. ProductDb is an entity that is a raw copy of the Product’s database equivalent, whereas ProductModel is an object that contains only those properties that are editeable. Every update should be performed on ProductModel-ish objects. Editing Db-type entities would skip Business Logic layer and is not supported.

To visualize the difference between ProductDb and ProductModel lets count properties of both objects – first one comes with 132, the second one with 110(mostly sublists and mapping properties are missing, as they shouldn’t be edited in other way than shown later in this article).


Adding new entities is fairly easy, but we have to remember that every object, when created, has its properties set to their default values(0 for int etc.). In this example ProductType can’t be left unset, because it’s an enum that doesn’t contain a value corresponding to 0.



Editing entities works similarily:



And deleting them:



On product it is also possible to use Search function. In order to do that, we will create SearchModel with properties set to desired filters:


Adding new categories is analogical, so I won’t cover it here. What is more interesting, is linking one entity to another. For example, let’s add our „New Product” to category „New Category”. We can achieve that by adding a suitable record to Products „ProductCategories” sublist. As said before, sublists, mapping properties, etc. must be edited accordingly to Business Logic, so we will use an appropriate method from Product enitity. Always remember to end request with „GetValue()”, otherwise it won’t have any effect.



Deleting mapping between Product and Category isn’t rocket science either:



back to top