I want to understand the main difference between a flowable task and http task. Why should we prefer one over the other and when is it better to use flowable task or http task?
What exactly do you mean by Flowable Task? In case you mean the Service Task then the Http Task is just an extension of the Service task that has specific functionality provided out of the box to easily send HTTP requests. You can also achieve this by implementing some logic to a Service Task. The only difference is that the Http Task is specified for sending Http requests and you can simply use it and provide the endpoint you want to call.
Related
Question about Karate: can the .feature Mock files intercept calls from back-end Java service class?
I think the mocking feature is pretty easy to understand. I can see that you can start the mock server in the background step and then your scenario HTTP calls will be intercepted BUT
My question is: is it possible to intercept HTTP calls coming from my back-end service class after I hit my API endpoint with a Karate step?
If I don't get an answer, I will put together a sample project and experiment. Just hoping someone knows off-hand. If not, I think I can probably run an instance of Mountebank.
It may be possible by telling the JVM to use an HTTP proxy, but it depends a lot on the system under test.
You can find more details here: https://stackoverflow.com/a/61414022/143475
I have got the following question about the pipeline design..
Can you please help me understand what we should be doing inside the request pipeline and response pipeline?
Let's say.. I am designing a proxy service that calls 2 separate business services and sends the response to the caller..
The proxy service will have assign, service callout, routing and reply action. I can do everything inside the request pipeline and I don't understand the purpose of the response pipeline.
Can anyone help me understand what we should be doing inside the response pipeline?
Thank you
A typical scenario in an OSB pipeline would be to validate, transform and enrich the request in the Request Pipeline, Route to a business service (which appears after the pipeline pair), then validate, transform and enrich the response in the Response Pipeline. In this case in your pipeline, after the Pipeline Pair node, you will have a Route node.
Often people will use a service callout instead of a Route node. In that case, you may not have anything (like a Route node) appearing after your pipeline pair and you can do everything in the Request pipeline.
You should understand the difference between a Route node and a Service Callout. Routing to a business service uses non blocking IO compared to a Service Callout which will block a thread, so using a Route is the much more scalable option.
I thought using RPC is bad practice but all the resources I am finding point to using RPC in order to get a response from a queue after publishing a request. Are there any other ways of doing it? Is it the best practice?
Thanks
MassTransit has built-in support for producing requests (which can be published, or sent directly to a specific endpoint). The request client can be created manually or added to a dependency injection container, and one or more response types can be handled.
MassTransit uses the bus endpoint to receive responses by default.
To register the request client in the container, the AddRequestClient method is used as shown below.
services.AddMassTransit(x =>
{
// configure transport/host/etc.
x.AddRequestClient<CheckOrderStatus>();
});
RPC is a common pattern, and producing requests when a response is required, it a regularly used approach. Another option is combining a command with an event, and observing the event separate from the request producer. However, if a linear programmatic flow is required, using RPC via the request client is an easy solution.
I have a scenario in which I need to share some per request data from WCF authentication module to actual service method. I also want this data not to be sent to client. What is the best way to achieve this?
Maybe you are looking for this: WCF Intermediate Service between Client and Server
How can I build a synchronous WCF service that wraps asynchronous MSMQ communications?
Let us have a simple scenario. I have a client which supports only synchronous web service calls. I need to send a synchronous request for "Order", but the back end system exposes this as an asynchronous request and response MSMQs. The WCF does not need to have any logic just wrap the MSMQ asych communication and pass parameters back and forth.
Grateful for your help
Let us have a simple scenario. I have a client which supports only synchronous web service calls
Synchronous call means you are using same link (end point url) or channel for your communication between client and server, so according to your assumption no.
Reason: Every time your client will send a request, it will keep waiting for response from server and will produce error.
Alternatively,You can define two services (different end point url) in your wsdl or webservice, one for request and one for response.
At client side you need to invoke these end point url saperately for sending request and receiving response,so it will appear as synchronous but ultimately it will be asynch. Thats all you can do in this scenario.
As per my understanding.