I am using the Pact framework to test some APIs from a service. I have one API that initiates some backend execution. Let's call it request A and the response returns a unique execution ID. The second API (request B) send the execution ID returned from request A to pull the execution status. How do I set up the pact test in this case? The problem is the execution ID that is generated dynamically. I know a provider can inject some provider state to the consumer. So potentially, the execution ID could be injected. But I am not sure how to make the injection from the provider side. It requires access to the response from the response A and inject the execution ID (with the provider state callback, perhaps) for the second request.
You need to have a lot of control over what is happening in your provider for Pact to work for you.
Each interaction is verified individually (and in some frameworks, in a random order), and all state should be cleared in between interactions, so you need to use provider states to set up any data that would have been created by the initial request. In regards to something like the execution IDs, you could use a different implementation of the code that generates the IDs that you only use for Pact Tests.
Related
I'm performing some logging in our ASP.NET app, using a custom ActionFilterAttribute. I'm adding logging for both the income info (via OnActionExecuting), and outgoing (via OnActionExecuted).
We have a call token (GUID) that I have access to in OnActionExecuting, and is part of the information being logged. I'd like the same token to be used in the logging done in OnActionExecuted.
My questions:
Is one instance of ActionFilterAttribute created for each incoming call?
Is this the same instance used for both OnActionExecuting & OnActionExecuted (allowing me to store the token as a member variable)?
Since no one has replied, and I got an answer through my own testing, I thought I'd post an Answer here.
It turns out that an instance of the action filter is created and shared among various controller action calls. Therefore using a member variable to share common data between a request (setting it in OnActionExecuting) and a response (reading it in OnActionExecuted) is NOT a reliable means on accomplishing what I intended.
There is a bank which creates a contract which is then accepted by the lender and the borrower. After signing the contract the lender provides fund to the borrower. The bank then creates an obligation state based on the data received by calling an external service automatically.
And Now
1) In API Layer, I am calling first flow which creates one state.
2) In API layer itself, On success of first flow , I am calling the http request to external service and get the data.
3) Now I pass the http response to the the second flow for creating the other state.
Can you please let me know if there is any issue with this approach.
Requirment is I want to trigger the first flow manually, but calling external service and initiating the second flow should happen automatically
I had referred the link given below.
Making asynchronous HTTP calls from flows
You'll make calls to an external service during the running of flows.
The best place to get started would be looking at the CorDapp samples here. In particular, take a look at the Accessing External Data section
We're building a microservice app where clients can create projects. The following diagram shows the technical flow of this process:
My question: what HTTP response should the API gateway return to the client (step 1.)?
My initial idea was to give back a 202, but the problem there is that I don't know the Location yet (/projects/{id}), because the id of the project will be created at the Project Management Service.
Considering that the IDs of the newly created project entity is not known at the request time (i.e. it is generated after the insertion into the database) you indeed cannot generate the url to the project resource.
Instead, you could assign an ID (i.e. 1234-abcd-5678-efgh) to the command before sending to the bus and keep track of its execution status on the API gateway itself. Then you can respond to the client with an command execution status endpoint like /commands/1234-abcd-5678-efgh where it can query by polling.
The alternative would be to use another service that would reserve&deliver unique IDs but you must make a blocking call to it and this hurts scalability. Or you can host this service inside the API gateway itself (onto the same node) to minimize latency. Also, there is a risk of loosing some IDs in case of project creation failures but this can be compensated by releasing those IDs in those situations (thus increasing the architecture complexity).
A third solution could be the use of a project surogate ID, like a GUID, assigned as a property of the project, included in the command, having the purpose of an alternate identity that can be used only in the pre-creation phase of the process. Then, the response to the client could be like this: /projects/by-guid/1234-abcd-5678-efgh and after the project is created a GET to this url would permanently redirect to the final project url.
I have read that on Pact, the consumer is the one initiating the request. I have a service (let's call it A) that is used to draw pictures that will then be submitted (via POST) to a service (let's call it B) that will process those inputs and generate albums.
My question is: If the service B is the expert on knowing which kind of inputs and in which format should receive in order to create albums, how come is service A the consumer and therefore the one that will be writing the contract? Shouldn't it be the service B that specifies what kind of data should be receiving?
From [1]:
A component that initiates a HTTP request to another component (the service Provider). Note that this does not depend on the way the data flows - whether it is a GET or a PUT / POST / PATCH, the Consumer is the initiator of the HTTP request.
But I think your question is really asking about consumer driven contract testing [2]. You're conflating who is building the service with expertise / understanding of the requirements for its existence. The Consumer knows what it needs from the service, and the Provider knows how to implement it.
Consumer driven contracts reverses the typical API design process of creating an API first and then consumers coming along to use it. First, the consumer specifies what it requires, publishes the expectations as a contract and the Provider then implements it.
Pact generally assumes this mode, but it's not strictly necessary (i.e. the Provider API can exist in advance).
[1] https://docs.pact.io/documentation/how_does_pact_work.html
[2] https://martinfowler.com/articles/consumerDrivenContracts.html
I am using spring boot for developing services in my application.
I have a scenario where-in the request submitted to the back-end would take some time to complete.
To avoid waiting the client I want to return the response immediately with a message your request has been accepted. The request would be in progress in a background thread.
I see Spring provides the #Async annotation which can be used to create a separate processing thread from the main thread and using that I am able to offload the processing in a separate thread.
What I want to do is when I return the initial response as accepted I also want to provide the client with a tracking key/token which the client can later use to check the status of the request.
Since there can be multiple clients who would be accessing the service there should be a way of uniquely identifying each client's request from another.
I see there is no such feature in Spring Async or Future which can return a tracking id as such.
One possibility I see it to put the Future returned in HttpSession and later use that to check for the status by the client. But, I prefer not to use HttpSession and want my services to be stateless.
Is there any way/approach I can accomplish my requirement.
Thanks,
BS
Generate the key before calling the Async method, and pass it to the method:
String key = generateUniqueKey();
callAsyncMethod(key);
return key;
The Async method will have to persist the status of the execution somewhere (let's call it dataStore). When the client asks for the status using the key, you look it up on the dataStore and return it.