I'm trying to call ServiceStack service from a console app with a service reference client (generated after using Add Service Reference in VS 2010).
I looked at the sample at github but was unable to create a similar client code.
My objective is to provide a set of services with a simple API that can be called by a .NET client as easy as possible. Ideally, client should not need any knowledge of ServiceStack to call the services.
My questions are:
How should I create request if the service does not need any parameters?
How can I resolve proxy.Properties?
Here is the gist
You can use SOAP/WSDL's Add Service Reference but you should be mindful of SOAP's Limitations.
Although the current recommendations for client libraries is to use your preferred choice of ServiceStack's built-in generic service clients.
Got it working, updated gist Removed properties, version, request
Related
so i am able to call app insight's api "https://api.applicationinsights.io/v1/apps/xx/xx/xx" from my C# code.
i can get the json response.
i have this response in json and i want to serialize it into C# objects. do i have to create matching C# classes my self or is there any built in c# models i can use and serialize them?
Not really a direct answer to your question, but instead of consuming REST API directly and doing the conversion/serialization yourself you can simply use Application Insights .Net SDK.
The SDK will do all the necessary conversions for you and give you nice C# objects. The source code for this is also open source and is available here: https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/applicationinsights/Microsoft.Azure.ApplicationInsights.Query.
You can take a look here for all the models available to you for direct use here: https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/applicationinsights/Microsoft.Azure.ApplicationInsights.Query/src/Generated/Models.
In my opinion, if you choose to use app insights api, that means you didn't add any other sdk into your project, that means there's no any built in models for you.
And if you choose to use sdk instead, here's a sample for it, and per my testing, it only provides QueryResults as the response, here's my testing result， and this is the introduction for preparation. Pls note, you need wait for a while to make the newly added role to take effect. If you can't find the api permission mentioned in the document, you can search for it like what I did.
We understand that these are the options available from SDK to connect to ODATA Service
Option 1 - If the ODATA Service is not supported implicitly by SDK, Use com.sap.cloud.sdk.odatav2.connectivity.1.ODataCreateRequestBuilder
Option 2 - If the ODATA Service is not supported implicitly by SDK, Use VDM generation approach.
Call the services using generated Java classes
Option 3 - If the ODATA Service is supported implicitly by SDK, Use the already available class
e.g. 2> com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService
Now we have have some questions and need expert guidance here
Question 1 - We have a use case where we need to call oDATA Services from a third party system
which option we should go for Option 1 or Option 2 ?
Question 2 - What are these cases where Option 1 is preferred over Option 2?
Question 3 - We also have a use case where we need to call S4HANA ODATA service related to OutboundDelivery. Service is supported by SDK by class com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService
But there is one new field is getting added to the service during current release. We need to update this field
In this case which option is suggested?
Question 4 - How frequently new fields on existing S4HANA odata services are included in SDK?
I hope I can enlighten you a little here:
Regarding 1: Personally, I'd still recommend going with option 2 and generate client code using our generator. This will give you the same convenience that you know from the S/4 services for any other OData service. If, for some reason, the generated code does not work against your third party service, you can still use option 1 as a fallback.
Generally speaking, our generator should work for any OData v2 service, not just SAP services.
Regarding 2: As already mentioned, the generic OData client always works well as a fallback, if the generated client does not work whatever reason.
The other case I can think of (and this should be rather rare), is that you yourself are exposing one service that retrieves it data from several downstream OData services. In this case, the generic client might give you some advantages over the generated one.
Apart from that, I'm not aware of any use cases where I'd personally go with the generic client over the generated one.
Regarding 3 and 4: The VDM packages that we ship as part of the SAP Cloud SDK contain the OData client code for the current release of SAP S/4HANA Cloud. So if the services in SAP S/4HANA Cloud are updated, our packages will reflect that update. If you're working with SAP S/4HANA On-Premise, there's generally a good chance that the service is compatible with the Cloud version. If not, you can still use our generator to generate client code with the metadata of the respective On-Premise service.
Looking at the list of available polarion webservices wsdl api functions, I don't see one for creating a polarion user. I have had no luck in finding out how I can create a polarion user via scripting to the polarion soap (wsdl) API. preferably in Python.
I have not tested it but Polarions Java doc says it is possible with the ProjectWebservices class:
http://almdemo.polarion.com/polarion/sdk/doc/javadoc/com/polarion/alm/ws/client/projects/ProjectWebService.html
I actually recommend to work with Java as the API seems to be catered to this. I have not tested however if it is even possible to set up Python scripts accessing the API.
What is btw definitely NOT possible is creating projects via the API, see my answer here:
Polarion Web services API - How to create a project?
Given the most awesome release of the Visual Studio Extension for ServiceStack, I wanted to make sure that after creating my service with ServiceStack, that when I create a client to consume said services that I'm doing it correctly. By that I mean in a loosely coupled, high performance way.
Let's say that we examine the EmailContacts project so we're all on the same page. The Email Contacts project has a reference to both the EmailContacts.ServiceInterface and EmailContacts.ServiceModel, this is understandable as this IS the service. Now I want to consume this service from another .NET project, doesn't matter what type, console or web.
So my question is this "In the consumer application, will I add a reference to EmailContacts.ServiceInterface and EmailContacts.ServiceModel and use the ServiceStack C# client library?", I don't see where I have a choice not too.
Thank you,
Stephen
Keep Service Models in their own Assembly
The benefit of having a well-defined Service Contract where your DTO's are maintained in their own separate impl-free project is that clients will only ever need to reference your Services DTO's to use with one of ServiceStack's C#'s Generic Service Client to call any Service.
Add ServiceStack Reference
Clients are also able to avoid referencing any of your Server dlls if they use ServiceStack's Add ServiceStack Reference feature which provides another way for clients to access your Web Services DTO's.
Clients shouldn't reference any Server implementation projects
It's a code-smell if you find clients needing any reference other than your Service Model and ServiceStack's client libraries, which is an indication that your Service Models aren't in their own dependency and impl-free .dll, which shouldn't depend on anything other than ServiceStack.Interfaces.dll.
I was wondering whether or not BreezeJS is compatible when using other technologies other than Web API and/or Entity Framework? As I'm currently in development of a SPA using Service Stack to retrieve data and ORMLite?
So I am curious how BreezeJS handle's this as I know it uses it's own API Controller usually with an extension of the DbContext class which Entity Framework uses. Thanks.
There is currently a sample called NoDb in the samples zip available on the breeze website. This sample does not use EF, but it does use WebApi. So I'd start by looking there. ( additional documentation on this sample should be added within a day or two as well).
In terms of using ServiceStack instead of WebApi, breeze supports the concept of a "dataServiceAdapter" and currently ships with two, an OData adapter and a WebApi adapter. It is certainly possible to write a ServiceStack adapter that breeze could use but this is not trivial. Please add this as a feature request ( and vote for it) on the breeze User Voice. We take these requests seriously.