We are using SAP S4HANA SDK Springboot archetype to build the application in SCP Cloud Foundry.
The requirement is to fetch the OData services from the SAP S4HANA and expose them to the Fiori UI frontend in the form of OData.
From the Java web services, we are getting the responses in JSON format:
Output what I need is in the below oData format.
This is one of the services and the same should be made available to all the java rest services. Found out Apache Olingo for converting it into odata format. But wanted to know if there is any method class in SAP SDK which supports this.
There are several possibilities to solve that problem:
You can fake it, i.e. manually translate all the results into XML yourself just enough so that UI5 accepts it.
You can expose an OData service from your backend using the SAP Cloud Platform SDK for Service Development (that is already modeled as a dependency of the SAP Cloud SDK). You can find information on how to do that here and also here.
Have you considered calling the OData service from your frontend directly?
Related
I have a remote server installation of the Camunda BPM Platform (installed using the Camunda BPM Platform Helm Chart - https://github.com/camunda-community-hub/camunda-helm/tree/main/charts/camunda-bpm-platform). It is working as expected and, while new to BPM, I have been able to try out some workflows and examples successfully.
I am now trying to connect to it remotely and register for thrown events. I've been following https://docs.camunda.org/manual/7.15/reference/bpmn20/events/signal-events/ however I am stumped as to how I can get a handle to runtimeService. Other than using the REST API is there another way to connect to a remote Camunda service? I've tried using the camunda-bpm-spring-boot-starter-external-task-client but no RuntimeService gets initialized. Perhaps I'm missing some remote-specific configuration but I have not found anything in the documentation so far. Based on https://camunda.com/best-practices/deciding-about-your-stack/ I understand that this should be possible - however, all examples I've found deal with an embedded service. Any help is appreciated!
CAMUNDA offers a Java API and a REST API. In addition there are official or community client libraries, which all rely on the REST API. The Java API is only available to code which gets deployed inside the CAMUNDA JVM.
To interact with the engine from outside the JVM you have to use the REST API. The endpoints are named after the resources, not after the Java API services. Hence you You will not find a RuntimeService endpoint on the REST API, but you will find all the functionality the RuntimeService offers, e.g. start via process-definition.
If you do not want to deploy code in the CAMUNDA JVM, then service integration is done preferably using the external task pattern. If you want to use Java, especially the new Spring Boot Starter for external task clients is fun to work with. If you prefer other languages, check out https://github.com/camunda/awesome-camunda-external-clients.
Unfortunately there currently is no implementation type external for signal events so far. Ootb you can work with signal events for 1:n communication between different BPMN processes on the same environment. If you want to send the signal to an external event bus, then you need to add this functionality to the same JVM as a one-time effort. Here is an example for Azure event bus: https://github.com/camunda-consulting/code/tree/master/snippets/engine-plugin-signal-to-azure-eventhub. The implementation would look very similar for SQS or other alternatives.
If you need to modify the container image to include custom code then you can either just add own jars to e.g. the CAMUNDA RUN Docker image as shown here: https://github.com/rob2universe/bpmrun-add-to-dockerimg
or you could build your own image based on the Spring Boot Starter as shown here: https://github.com/rob2universe/camunda-aks
Azure functions use HTTP trigger(HTTP protocol) not exactly the REST. Enough resource is available for API documentation for Spring-Rest but not for Spring-Azure
The official way to generate OpenAPI definitions with Azure Functions is to use Azure API Management (APIM) to generate it for you. There is even a consumption tier for APIM which pairs well as a custom gateway for Azure Functions.
The same should work with Spring Cloud Functions deployed on Azure too.
We have some legacy OData service code in our application which is written using a WCF Data Service.
Everything else in our system now uses Web API as the data interface so I am wanting to port our WCF OData Service to a Web API service with the OData annotations.
My question is, we currently use the OData service for standard CRUD statements and also a lot of Service Operations. Are there any limitations with Web API OData that would limit it compared to WCF Data Services (i.e relationship chains, service operation calls, etc.)? I'm wanting to get away with updating the service so the client side of things doesn't have to change at all.
I've started working on a similar port from WCF to WebAPI for OData with the recent release of Web API 2 and its support for $select and $expand - until then I could not really replace the data service. Service operations can be added as actions
I am using AMX Service Bus 3.2. and trying to expose my rest services (ASP.NET WebApi) through the TIBCO Active Matrix. Unfortunately I have not found any way to do this in TIBCO business studio.
I found TIBCO Active Matrix Binding Type for REST but it is intended only for promoted services. It allows to expose SOAP services via REST interface but it is unable to invoke my REST services hosted on IIS.
As for now I see the only one way to implement that - Create addition SOAP service that will redirect HTTP request from Promoted service to my REST Service. But such solution is not very good SOA design.
Any help is appreciated.
im trying to understand where WSDL's fit in, in a typical web service backend application. i am coming from a Spring background and in my experience so far, in Spring, each url request gets mapped to a specific controller class via a dispate servlet running in the web container. you can specify which url matches a given controller via xml config or from annotations.
is using a WSDL the same thing as using an xml config file to map url requests to java objects?
Thanks in advance. im moving from Spring to standard j2ee/EJB3.
WSDL is just a description of Web Service interface, most Web Service systems generate those descriptions on fly like for example when you create asmx web services you can generate WSDL on fly by typing http://yourhost/yourwebcontext/yourwebservicename.asmx?wsdl and it will return you the description of that web service. Then you can use a tools that generate stub proxies for coding using those descriptions automatically, for example in Visual Studio when you add an Web Service Reference those operations are done automatically
No, WSDLs are not like a dispatch servlet.
A WSDL file is a description of a web service (SOAP, REST, etc.). A WSDL can (theoretically) be used by anyone to generate executable code which consumes the web service described by that WSDL.
From the WSDL tag info:
"WSDL" stands for "Web Services Description Language." It is an XML language used to describe a web service to code that wishes to consume it. It describes the messages sent and received, the possible faults, and the communication and security requirements.
From WSDL Essentials:
In a nutshell, WSDL represents a contract between the service requestor and the service provider, in much the same way that a Java interface represents a contract between client code and the actual Java object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services.
Using WSDL, a client can locate a web service and invoke any of its publicly available functions. With WSDL-aware tools, you can also automate this process, enabling applications to easily integrate new services with little or no manual code. WSDL therefore represents a cornerstone of the web service architecture, because it provides a common language for describing services and a platform for automatically integrating those services.