I am new to spring integration and learning in the process.
I will have to make two SOAP calls.
1st SOAP call --->use the 1st call response as 2nd SOAP request.
And programmatically get the url and other request parameters from the database.
I was successfully able to make the call with this configuration
<int-ws:outbound-gateway id="Service" request-channel="requestChannel" reply-channel="responseChannel" uri="http://localhost:8080/core/v1" marshaller="marshaller" unmarshaller="marshaller"/>
I haven't used any activators or interceptors. just used xml and gateway interface. I have hardcoded the request values.
Can someone help me how to get values from database and build this in a much better way.
Use JDBC Outbound Gateway to retrieve data an pass it into WS Outbound Gateway.
You can find some samples on the matter: https://github.com/spring-projects/spring-integration-samples/tree/master/basic/jdbc
Related
I have a service with many controller methods. My task is to "split" this service into microservices.
The microservices themselves will be deployed on other machines. Nginx redirect by location.
The main problem is that there is one location, http://mydomain/myservice/srv/data that receives different types of requests.
And the logic after is called based on the value in the a field in the request body.
For example, two requests:
<request type="getname" val="1"/>
<request type="balance" val="1"/>
The first request must be forwarded on http://mydomain/myservice1/data/name and the second on http://mydomain/myservice2/data/balance
Question: Are there any libraries for such purposes?
UPD: I am writing simple jar based on RouteLocator (spring cloud); is there perhaps another way of doing this? Spring cloud not is the stack we're familiar with.
You may have a look to spring integration, it implements most of the enterprise integration patterns, including content based routing
I think the approach of proxying the request based on different request types in the body is not a good way to proxy. The URI ultimately should be responsible for what kind of request it is serving and response it should be responding to.
The client has all the necessary information on the request type and therefore where to send the request. From that fact, I would refactor the resource that you have to different resources that handles the different request types and determine an explicit schema for the payloads for each one.
To summarize, the implementation would look like the following:
Refactor server logic for different types of requests to their own resource URIs
Move the logic of where to send the request into the client, perhaps utilizing something like a factory pattern
In a simple #EnableZuulProxy application, requests with Content-Type application/x-www-form-urlencoded or multipart/form-data gets wrapped in a FormBodyRequestWrapper by FormBodyWrapperFilter. This decodes the content and reencode it for the backend.
However, from what I can see, requests of other content types (let's say application/json) in a service discovery enabled route will get their InputStream directly proxied to the client used through the RibbonCommandContext.
In Apache HttpClient for example, the input stream will be wrapped in a BasicHttpEntity in the RibbonApacheHttpRequest.
Why is this necessary? Couldn't we just handle all requests the same way?
See https://github.com/spring-cloud/spring-cloud-netflix/issues/109 for the original issue.
The zuul request wrapper buffers the request and it needed to be added back for the proxy. This is one of the reasons spring cloud gateway was built, since it doesn't have these problems.
I'm using the Apache CXF library to consume a SOAP Web Service. This service requires a saml:assertion (SAML 1, not 2) in the payload header. I want to use an encoded SAML token that is given to me. How do I add this token into every request going to the external SOAP Web Service?
I've been playing around with the AbstractSoapInterceptor and the SamlTokenInterceptor, but I haven't gotten it to work yet. The interceptors require a Phase string, and I'm not sure which one suits my needs.
You could take a look at the CXF system tests. See here for a SAML example:
https://github.com/apache/cxf/blob/9e6d2aa86c57e600baf66e42538036c927cadcf5/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/action/ActionTest.java#L423
Spring configuration:
https://github.com/apache/cxf/blob/9e6d2aa86c57e600baf66e42538036c927cadcf5/systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action/client.xml#L351
If you already have a SAML token you can set that on the SAMLCallbackHandler directly via this method:
https://github.com/apache/wss4j/blob/eb3dc39b397f571746ee9183ecb96eac3206fa9f/ws-security-common/src/main/java/org/apache/wss4j/common/saml/SAMLCallback.java#L313
To give you a background, upon receiving a request we want to extract the payload along with other information like request URI, query parameters, etc. and put it as a message in a Message Queue. Another service will then pick messages and invoke Katharsis so that the proper Controller will process the request. This is to create an asynchronous processing mechanism.
Now to invoke Katharsis manually we need to implement KatharsisInvokerContext which requires to create HttpServletRequest and HSResponse. However, since this is happening in the server we want the response goes back the the original requester.
Does anyone know how to do this or whether we are doing it wrong way? I'm open to suggestions.
We are using Spring Boot, Katharsis-core 2.0.1 and Katharsis-spring 2.0.3.
I am wondering how I can use google protocol buffers to accept a request and send a response back to a client? I am thinking about writing a servlet which will take a request.
Is the following trail of thought the correct way to implement this:
1. Have a .proto file which is the message definition for the incoming request.
2. Write a servlet which accepts this request, does various tasks like querying database
and then sends a response. Will this response require a separate .proto message definition with all the fields that make up the response?
3. Will the client just invoke the doGet() method of my servlet and pass the request, it should then return a response as a protobuff object?
Any suggestion or idea will be very much appreciated.
Typically you'd want a request message and a response message, yes. You'd also probably want a method name to describe the action - that's certainly how the built-in PB services work.
The client wouldn't invoke doGet() - it would make a request (probably a POST rather than a GET) and your servlet would receive it.
Now, ideally you could have a general "ProtocolBufferServlet" which could service the requests by handing them off to services implementing the appropriate interfaces.
I suggest you look at the documentation for Protocol Buffer services and the Java services generated code for more information. You could implement an RpcChannel which worked over servlets, or get the client to make the HTTP post directly. You'd probably use dependency injection of some kind at the server side to tell the servlet what was implementing the service.
HI,
I have this up and running. I ended up posting a http request as a post to my servlet. I was able to take the request protocol buffer, read the request, do some processing and then send back a response. It was actually really simple once I got it working. We used the 1 .proto file to define the request and response message structure.