JaySvcUtil.exe update – filter on what gets imported from OData metadata

Author: Peter Aron Zentai June 13th, 2013

, ,

JaySvcUtil generates a fully working client environment from OData metadata document by creating the necessary client classes (types) and boilerplates required to access the service. If you are new to JaySvcUtil read the announcement post.

Up until now the metadata document was converted on a 1-1 way: everything that was in the metadata document got to he JavaScript layer.

With smaller OData services this behavior is quite alright. But with larger implementations, for example Microsoft Dynamics CRM, the OData endpoint gets HUGE, resulting in a HUGE client code set. When I say huge I really mean HUGE: out of the box over 200 entity classes, several thousand relations and fields, etc. While it is still a working approach to get it all, such a huge library takes significantly more time to boot up. A fully detailed MS CRM environment generates in as much as 1000-2000 milliseconds – or even more on slower devices.

But do we need all these classes and navigation info all the time? Most use cases tend to be focusing on just a very little subset of the whole data model: for example a simple expense report feature developed for a mobile app will only need no more then 4-5 classes from the total 200. Same is the case with a simple Product lister/ordering app.

The new features in the most recent JaySvcUtil.exe let you fine tune what gets imported to achieve a significantly smaller overhead and sizes in terms of execution time and memory.

New command line parameters in JaySvcUtil

-f, –typeFilter switch

Narrow the import to specific entity types or entity sets. EntitySet names must be specified with their respective container. You can also specify what fields should be imported – otherwise all fields and navigation info will be.


-f setOrTypeFilters


setOrTypeFilter[;] 1 .. n




fieldName[,] 1 .. n  remark: if no fields specified then all fields are implied. There is no way to express empty (zero field) entities.

Example #1:

This will export the Lead type with all properties and navigation properties and with all linked dependency types discovered on a recursive manner.


Depending on the structure of OData metadata this could export only a solo type – or because of the web of dependencies a solo type can lead to importing the whole data model. This is the case with for example Dynamics CRM or SharePoint.

To avoid pulling in all the data model as a result of dependencies you can disable navigation properties (see below) or specify the exact fields list to be imported on the Lead type and on the types that will be pulled in the export via navigation field.

Example #2:


You can also filter referencing EntitySets insead of types.

Example #3

You need to lookup your ContainerName – it is really depending on the OData backend you are using, check for this in the metadata:

-t, –typeFilterConfig switch

Similar to the –f filter as above, only that settings are passed as an XML file. An example of such a filter file is:

 -N, –navigation  switch

Enable or disable processing of navigation properties. This is a true/false parameter with a default value of true. Set this to false in order to avoid importing any navigation properties. To import some of the navigation fields you should leave switch on true and list the required navigation fields.

-D, –dependentRelationsOnly switch

Given a set of types or entitysets this switch narrows the navigation import respective to only those types. For example

will import all properties from the Lead and Product type, plus any navigation properties that are corresponding to only these two types. Other navigation fields that lead to other types will not be followed or exported.

-K, –generateKey

Import the primary key field or fields regardless of any other filter settings. Default is true.

, ,