When using RIA services, how do I specify I want to use OData instead of a proprietary format?
I'm new with Odata but currently works on RIA and I found the article from Brad Abrams blog at
http://blogs.msdn.com/brada/archive/2010/03/16/silverlight-4-ria-services-ready-for-business-exposing-odata-services.aspx
After finished prepare everything such a service, you can specify to use OData by calling URL to the DomainService like
"http://localhost:7777/Sample-App-GreatDomainService.svc/OData/YourObject"
Which,
Sample-App-GreatDomainService.svc = Your domainservice namespace(Mine is Sample.App.GreatDomainService) and followed by .svc (see that '.' replaced by '-')
/OData/YourObject = Exposed to the typename in your data model as OData (Mine is "YourObject" type)
This will get an Atom Feed data of type "YourObject" in your project.
Hop this help. ^ ^
Related
I want to get all destinations on subaccount and instance level. In SAP API business Hub, I found the API information and "SAP Cloud SDK" tab to generate code by OpenAPI generator.
https://api.sap.com/api/SAP_CP_CF_Connectivity_Destination/overview
I downloaded the API specification and added dependencies into Cloud SDK for Java project. The code is generated successfully with some errors (unknown models）in generated api classes.
For example in DestinationsOnSubaccountLevelApi.class, model OneOfDestinationNameOnly is imported and used in method but it is not generated in model package.
I looked into API specification and found that there were two types of response entity. That is the reason why the code could not be generated properly. I can modify the API specification to make it work but it should not be the long term solution. Is there any other way to fix this issue?
Unfortunately the SAP Cloud SDK Generator for Open API services is not yet able to understand oneOf relationship that is modeled in the specification.
As an alternative, would you consider using the DestinationAccessor API for resolving single destinations?
You can also directly instantiate an ScpCfDestinationLoader, which allows for querying all destinations:
ScpCfDestinationLoader loader = new ScpCfDestinationLoader();
DestinationOptions options = DestinationOptions
.builder()
.augmentBuilder(ScpCfDestinationOptionsAugmenter.augmenter().retrievalStrategy(ScpCfDestinationRetrievalStrategy.ALWAYS_SUBSCRIBER))
.build();
Try<Iterable<ScpCfDestination>> destinations = loader.tryGetAllDestinations(options);
Similar to the default behavior of DestinationAccessor API, in the code above only the subscriber account will be considered. Other options are:
ScpCfDestinationRetrievalStrategy.ALWAYS_SUBSCRIBER
ScpCfDestinationRetrievalStrategy.ALWAYS_PROVIDER
ScpCfDestinationRetrievalStrategy.SUBSCRIBER_THEN_PROVIDER
Recently I needed to use the search REST API for a project, I found the documentation and do step by step as follows:
https://www.ibm.com/support/knowledgecenter/SSYJ99_8.5.0/Search-Rest-api/Search.html
But to search constraints, I use it according to the documentation, the results returned are incorrect.
Do I need to configure where in the portal to use search constraints ? I am using IBM WebSphere Portal 9 Build Level: 20161208-1058 2016-12-08 12:09 CF13. Thank you!
I use the link URL search REST API, as followed:
http://localhost:10039/wps/contenthandler/searchfeed/search?constraint=
{"type":"field", "id":"authoringtemplate", "values":["bidv-template-demo"]}
&queryLang=en
&locale=en
&resultLang=e
n&query=developer
&scope=com.ibm.lotus.search.ALL_SOURCES
&start=0
&results=10
I had read that the Azure Search .NET SDK uses NewtonSoft.Json to convert it's models to/from json in it's underlying REST API calls so I've been doing the same in my own app.
I have a simple app which creates a new Index using the .NET SDK. To do this, I was defining my Index in a json file, using the format outlined here https://learn.microsoft.com/en-us/rest/api/searchservice/create-index and then I was converting this to a Microsoft.Azure.Search.Models.Index object using Newtonsoft.
var index = JsonConvert.DeserializeObject<Microsoft.Azure.Search.Models.Index>(System.IO.File.ReadAllText("config.json");
This was working fine before I configured custom Analyzers, but now that I have custom Analyzers in my config, the Analyzers, Tokenizers, and TokenFilters are not being resolved into the correct types. ie. my custom Analyzer is being deserialized as a Microsoft.Azure.Search.Models.Analyzer, instead of Microsoft.Azure.Search.Models.CustomAnalyzer, same goes for the Tokenizers and TokenFilters, they are being deserialized into the base types.
Is there an easy way I can create an Index like this in the .NET SDK from a json file?
Unfortunately this is not an officially supported scenario. While it works for simple index definitions, we're working to understand what we need to do to be able to support all cases.
Please post your feature request on our User Voice page to help us prioritize: https://feedback.azure.com/forums/263029-azure-search
In the meantime, you might be able to get it working yourself by adapting the JsonSerializerSettings initialization code at the bottom of this file.
Is there a way to expose a Java rest web service in Liferay but not in a portlet, that can receive JSON request and store the data in Journal Article?
Therefore when a user logs into Liferay they will be see web content
Yes there is : JSONWebServiceActionsManagerUtil.registerJSONWebServiceAction
For instance :
Class<?> serviceImplClass;
Method serviceMethod;
Object serviceImpl;
String path = jsonWebServiceMappingResolver.resolvePath(serviceImplClass, serviceMethod);
String method = jsonWebServiceMappingResolver.resolveHttpMethod(serviceMethod);
JSONWebServiceActionsManagerUtil.registerJSONWebServiceAction("/yourwspath", serviceImpl, serviceImplClass, serviceMethod, path, method);
You should then be able to see the new web service in http://SERVER/api/jsonws
Well yes, Liferay has a full API (even JSON-based, SOAP optional, no classic REST though) that you can use. A simple Stackoverflow answer is not the right place to give a full introduction on how to work with Liferay's API, but you might want to look up Servicebuilder (which is used to create Liferay's API) and then look at JournalArticleService and related services: The Web Content Management API is called "Journal" in Liferay (for historical reasons)
We are using the ADO.NET Data Service Provider Toolkit to implement a custom OData service endpoint running inside SharePoint 2010 (using .NET 3.5).
When the service is accessed in the root of a site collection the returned base address is correct, e.g.,
http://localhost/_vti_bin/service.svc/ returns a base address (in the returned atom document) as <feed xml:base="http://localhost/_vti_bin/service.svc />
But when the service endpoint is accessed in a subsite, the additional path segments are ignored, e.g.
http://localhost/subsite/_vti_bin/service.svc/ returns a base address (in the returned atom document) as <feed xml:base="http://localhost/_vti_bin/service.svc />
Unfortunately, this incorrect behavior confuses PowerPivot (which seem to use the returned base address to access subsequent queries).
Is there a way to explicitly the xml:base attribute from within the provider code?
This can be corrected by using the same IDispatchMessageInspector trick (as used by Pablo Castro to support JSON formatting) and adding the following code:
HttpRequestMessageProperty httpmsg = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
UriTemplateMatch match = (UriTemplateMatch)request.Properties["UriTemplateMatchResults"];
match.RequestUri = new Uri(SPContext.Current.Web.Url + match.RequestUri.PathAndQuery, UriKind.Absolute);
match.BaseUri = new Uri(SPContext.Current.Web.Url + match.BaseUri.AbsolutePath, UriKind.Absolute);
which basically changes the Base and Request Uris to include the subsite path.