passing query param to REST service which is dynamic in nature in denodo - denodo

I need to call REST API from DENODO (I use denodo express 7) with dynamic query param. This query param value would come from another JDBC data source view so that I can straightaway limit the results.
I have tried using interpolation variables, for example:
http://<hostname:port>/path?id=#{viewname.transaction_id} but it goes as null always, not sure is this correct way of accessing the view fields?

Related

Vaadin 14 Grid Sort on Non Class Atrtribute

I am trying to sort a Vaadin Grid with a back end data source.
However, I want to sort on the outcome of a comparator method, not on a property of the back end data source. This is how the column is added to the table:
grid.addColumn(p -> p.getNumberOfChoices()).setHeader("Choices").setComparator((c1, c2) -> c1.getNumberOfChoices().compareTo(c2.getNumberOfChoices())).setSortable(true);
It appears that I must apply the setSortProperty() method to have the grid sort to attempt a sort, but since I do not have a class property for this sort, this results in an exception.
It is only possible to sort based on a comparator if all items are loaded into memory. This does defeat the purpose of using a lazy loading data provider. This means that you have two options:
Load all items into e.g a List and set them using Grid::setItems instead of using a lazy loading data provider.
Implement your data provider to have explicit support for whatever string you pass to setSortProperty(). The provider implementation can access the property string through Query::getSortOrders. In cases like this, you probably need to implement it to explicit check for that case to make it do a custom SQL query or similar to lazy load items in the desired way.

ADF - Odata - How to perform an optional select

I've created an ADF flow that loops over URL's to fetch OData using the OData connection.
However, not all fields are available in all URL's, there are certain ones that are available in one URL, but not in the other. A $Select is used to select the fields that we need.
Is it possible to have an optional selection (as in, if the path is not available, do not fetch this field and return null instead for instance)? Would help us a great deal.
I've tried adding ? after the field, but that does not work. $select=Field1,Field2,FieldOptional?
Thanks
As I understand you are trying to loop through a bunch of a URL and the query on the ODATA URL will change and so will be the fields . I think you can use a lookup where you pass the unique url and its gives the fields and then concatenate the url with the fields and make a odata call .

Find picklist values in Dynamics via the Web API

I'm trying to determine how I can find the integer values for picklist fields in Dynamics via the web api. I can access the basic metadata by using:
GET https://[COMPANY].api.crm3.dynamics.com/api/data/v9.0//EntityDefinitions(LogicalName='lead')/Attributes/
but for picklist values I don't see the mapping of the integer value to the displayed string.
Is there a table that holds all of this or a way to expand this information on the above call?
You can use this to retrieve.
https://[COMPANY].api.crm3.dynamics.com/api/data/v9.0/EntityDefinitions(LogicalName='{Entity Name}')/Attributes(LogicalName='{OptionSet Name}')/Microsoft.Dynamics.CRM.PicklistAttributeMetadata?$select=LogicalName&$expand=GlobalOptionSet($select=Options)
Reference

Web API - How to accept comma separated list of parameter values via query string

I have a Web API project I am working on in Visual Studio 2013, and I'd like for my Controllers to accept a comma separated list of values via the query string, similar to this:
http://localhost:12345/api/Procedures/1?embed=doctors,drugs&fields=fieldA,fieldB,fieldC
The reason for this is that I'd like to be able to control if related resources (additional tables) are queried via custom embedding using the embed parameter, and control what fields are returned from the base object using the fields parameter.
I've done some searching on Google but most of what is being suggested relates to extending IModelBinder (http://www.strathweb.com/2013/04/asp-net-web-api-parameter-binding-part-1-understanding-binding-from-uri/) or setting up a custom ActionFilterAttribute (Convert custom action filter for Web API use?) which seems like overkill for something relatively simple.
FYI I am using an Entity Framework dbContext class to connect to my database.
The comma character does not have any specific meaning in HTTP query strings so it does not get treated as a separator by out-of-the-box model binding mechanisms.
As far as I know the approach you mentioned with custom attributes is the simplest you can get. And it does not look like an overkill considering you will only implement the attribute once and use everywhere.

Desire2Learn Valence API, PUT CourseOffering 404

Based on the information here http://docs.valence.desire2learn.com/res/course.html#actions I would expect that to 'update' a courseOffering I would specify a PUT with a CourseOfferingInfo block, which only contains a few attributes. Every time I try this, I get a 404, not found - even using the same route for a successful GET (404 says org doesn't exist OR org is not an offering - neither is true). However, if I specify a CreateCourseOffering block (directly from a previous GET), the PUT works fine. Is this correct and the documentation not? Or are there other things I should look for in this scenario? The documentation says use CreateCourseOffering for the POST to create an offering… I simply want to update one attribute of that offering and as such thought the PUT was the way to go.
If you use the "create" POST route with a CreateCourseOffering block, this will create a new course offering, and send back the CourseOffering block for the newly created course offering (this will include the org unit ID value for the new org unit you've built).
If you want to update an existing course offering, you should, as you suspected, use the "update" PUT route with a CourseOfferingInfo block. Note that you must provide valid information for all the fields in this block, since when used successfully, the LMS will use all the properties you specify in that block for new values for the org unit. The StartDate and EndDate fields are particularly finicky: you must provide either a valid UTCDateTime value (notice that the three-digit millisecond specifier in these values is mandatory) or a JSON null value if the field is not applicable.
Why a 404? What you're seeing with the 404s and the data you're passing is likely down to the way the back-end service is doing data binding. It tries to de-serialize your provided JSON data (and query parameters) into data objects it can read/manipulate -- if you provide a JSON block that contains a superset of the properties it's expecting, then this may work (for example, if you provide a CourseOffering block when you're expected to provide a CourseOfferingInfo) as the binding layer may ignore fields it doesn't need. If the binding process fails, because you provide a value for a property that can't be bound to the data type expected, or because you fail to provide a JSON property field it expects, then this can cause the service to return a 404 (because binding/de-serializing incoming parameterized data happens at the same time as matching the URL route to an underlying service handler).
If you provide a JSON structure (and query parameters) that the web-service can bind to its expected data objects, but the values you provide are invalid or nonsensical, then this can cause the underlying service handler to respond with a 400 (signalling an Invalid Request). But in order to get this far, your parameterized data still needs to get properly deserialized and bound into data objects for the underlying service to examine.
We'll be updating the documentation to more explicitly draw out this fact. The safest policy from the calling client perspective is to pass valid JSON structures that are exactly what's expected by the individual routes, especially since the underlying back-end service implementation might change how it handles incoming requests.

Resources