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.
Related
I want to use the OData function SubstringOf in our filter expression. As of now I do not see any relevant api against GeneratedEntityName.PROPERTYNAME.
Is there a workaround to use substringOf incase the API is unavailable.
Using Java SAP Cloud SDK version 3.7.0
Unfortunately the feature you are requesting is currently not implemented. Due to dependency restrictions the SAP Cloud SDK will not be able to provide a native solution to use custom filter expressions.
new DefaultGeneratedService()
.getAllEntities()
.select(Entity.PROPERTY_NAME)
.withQueryParameter("$filter", "substringof('SAP', CompanyName)")
You will not be able to use other filter expressions by the VDM. So you have to construct the query string yourself.
We are planning to enable custom and type based filters sometime this year.
Looking for advice, not necessarily any actual code. I'm a consultant writing some de-duplication functionality into an existing SharePoint Online \ Azure functions solution for a client.
The requirement: I need to write an Azure function that pulls PDF's from a SharePoint library, so I can hash check it before running it through OCR (ComputerVision API), followed by some text processing and a final similarity check.
The challenge: The client environment is locked down to the n-th degree (financial institution) and I only have access to the Azure resource group I'm currently working in. The existing function app, used by other solutions, runs on runtime 2.0 and Linux. I need to use SharePoint CSOM to access the PDF's for the above mentioned checks, but runtime 2.0 only supports .NET Core (not .NET framework), and .NET Core doesn't support SharePoint CSOM. There is a workaround to get CSOM working in .NET Core by fiddling with target build settings, but then it still doesn't run on Linux. Logic Apps doesn't give me the granularity to run all the checks and balances I need to, and SPFX isn't really a solution to do nightly automated runs without some garish compromises. VM's are out.
Any thoughts or suggestions to get this up and running without shooting myself or my client in the foot?
Here's two options:
Using the raw REST APIs with .Net Core running in Linux. You'll need to figure out how to generate the auth token. I know it can be done but don't have sample code for you at this time.
If Node is an option for you, you can use PnP JS in a Node Azure function. https://spblog.net/post/2017/06/07/Using-PnP-JS-Core-(sp-pnp-js)-in-Nodejs-environment
Do not even bother trying to get the CSOM to work. Also I don't even see how SPFX will work in this case.
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.
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