May someone please explain what exactly acceptance test for QuickFix have to do(test for)?
Right now i have done several test that test the latency and througput of messages but i have no idea what the acceptance test for QuickFix shoud test.
I have searched over the net for this but i didnt manage to find the answer of the question. So if someone know what i have to test for or have done such test please write it here so i and other like me can see it. Thanks for all the help in advance.
By 'acceptance test' I'm assuming you are referring to some kind of conformance test? If so, then it depends on the business scenario that you are trying to test and how the FIX connection supports that. For example, you FIX connection might be a pricing feed. In which case conformance testing might cover:
Fix session level tests (i.e. checking both sides are conforming to the FIX protocol
Testing subscription to symbols and that prices are being received
However, if you FIX session was an order feed then tests would include order related scenarios e.g. testing that you can submit orders, receive order updates (fills, rejections and cancellations etc). Testing the behaviour of orders if you get disconnected (ie. do your GTC orders get pulled if you lose connection from the exchange etc)
An STP conformance test would hopefully result in answers to questions like:
How do I guarantee that I have received all the deals
How can I replay deals that might have been done whilst I've been disconnected?
How do I uniquely identify a trade? (i.e which FIX tags or combination of tags do I need)
Whether you are conformance testing an STP, pricing or orders fix session, you will always want to do the basic fix session level tests.
Do this help?
Related
I am using webview for logging in my application. If i log in that account on device A, device B automatically logs out. Thanks for the help
There are a couple different paths you could take on this one:
1. Fake the check if another device logs out.
For this one, whatever call you make to see if the user should automatically log out, inject a mock or a fake to force it to say "yes, log out".
I'd suggest combining this with a separate test on the backend that ensures that when someone logs in, the old credentials are flagged as expired as well. Between the two, you have good coverage that the system as a whole works.
2. Manually test this functionality with two devices.
This is pretty self explanatory, but trying to get two separate automated tests to run in the proper order on two different devices consistently is probably not worth the effort. Especially when a quick manual test can verify this functionality when a full end to end validation is required.
It wouldn't be a bad idea to do both options above. #1 for quick validations during development, then do #2 as part of your major release process.
I have been struggling to find a good architecture, or even any nomenclature for what I'm trying to do here. I'm looking for nomenclature so I can have a starting point for research. And I want the same for architecture, but I'll take whatever anyone wants to help with.
What I'm trying to do & learn about
In a nutshell I need my clients to exchange pub keys, and other security data such as ACL ID's, name etc.
Current architectural attempts
I'm currently using my server as a via point, mainly because I can't see any other way of doing this securely and this method uses many layers of security. I also don't know of any other method of going client app to app securely.
A client creates group and sends pub key to server, opens a live query to receive other users data. Other user (with secrets passed to user) queries server for pub key, then sends own data to admin user via server. Admin then sends remainder of own data. I'm leaving out trivial security details but this is the gist of what I'm doing.
Issues
This is really just logical back and forth, but I honestly don't know what I'm doing. I don't even know if what I'm doing is right or the best way, I've also got a crazy infinity loop I'm trying to solve.
I'm looking for some terminology, description and/or architectural pointers, I'll take any input I can get.
Forget terminology, nomenclature and architecture.
Define the problem you are trying to solve in a simple sentence.
Break down the issues into smaller pieces (bite size).
You send A data to server
What happens to the A data
Any feedback or acknowledgement from the target host?
What sort of application is this? Web, Mobile, traditional client/server?
The most elegant solutions are usually the simplest ones.
Sit down and determine whether you have a problem to solve in the first place.
I'm starting to integrate PayPal checkouts with a server workflow.
My basic need is to create an order on the server and ensure that the client can not modify it in any way.
Because of this requirement, I have already ruled out using the "simple" JavaScript-only solution, and I'm instead going for a server integration, calling my own URL endpoints for creating and capturing orders.
However, I have found that the client can just ab-use the actions.order.patch() method to modify almost every aspect of the order, including the amount and the custom_id that I'm attaching to the purchase_item.
Basically, It looks like I have absolutely no guarantee on the order contents, even if I created it on the server, is this correct?
In that case, it means I have to check each order's contents against the orders database of my application. It is possible, but I was hoping to not have to do that.
Any clues? How do you deal with this issue?
Thanks!
If you are particularly concerned about this scenario of patching down the total or other details before capture, the only way to ensure it has not changed is to do a server-side ‘get details’ call before the capture and at least validate the total amount value, as well as any other field you’re concerned about.
Otherwise, the usual general safety solution in ecommerce (for this as well as other potential issues that might crop up) is to simply capture and validate the total in the capture response. If the capture has a total you don't expect, issue an immediate refund or flag the occurrence for review before fulfilling anything.
I am trying to make a REST application where I try to hide to hide Business Logic from request and responses.
I have to examples which I don't know how to handle.
First example: I have a shopping cart and product x can't be ordered with product y. The client however decided to order them both. How can I give a proper error message or guide the client that this isn't allowed. Because giving an error saying "x and y are not allowed together" seems like exposing Business Logic to me.
The structure is in place because of different services that we have. The products can be re-used, but the order intake is different. For example we can offer an order intake for vehicles which need different configuration when ordering cloths. In both cases you will have product, which have name and price and therefore can be re-used. That's is why vehicles and cloths can't be ordered together and shouldn't. To make this more user friendly there will be a service which presents available options for the specific order intake. But there should be a part which validates it and gives proper error on this.
Second example: A client has one pending order and can't create a new order when the pending order is completed. This seems/feels stateful to me and should probably avoided. How should this be handled?
UPDATE So resolving the issue for my first example could be to create an endpoint something like /products?type=vehicle or /products/combinations?type=vehicle. This is for displaying the allowed products/combinations and have an endpoint /order to put the products in where the validation happens. These endpoints can stand on their own, but the context may come from somewhere else. Do I understand correctly?
As the other answer already pointed out, this is only marginally related to REST, it has I think more to do with the meaning of "exposing business logic" and "statelessness".
The first point of not wanting to expose business logic: It is only exposing business logic if some system really needs to interpret the specific error. If it is "only" supplying a localized message to the user, it is not exposing any logic to the systems in between. The frontend system does not need to know what is going on, it only needs to display the message from the backend system.
There are cases when the frontend system needs to know, to be able to guide the user. It is not fundamentally wrong to expose business logic, as long as it is not implicitly exposed, but explicitly part of the interface description.
On the second point about statelessness: REST defines that the communication needs to be stateless. That means any arbitrary request from client should be meaningful without the context of any previous messages (this includes previous logins, sessions, whatever). Each request stands on its own. This does not mean that specific resources can not keep a state of their own. A shopping cart on the backend does in fact has a state, this is OK.
Or said differently: Can the next request hit a different server and still be successful? And I mean without session replication, distributed cache or other magic. If yes, the communication is stateless. If you need "sticky" sessions or such things, then no, you are not stateless.
I think your questions are not entirely related to REST itself but I will try to answer them anyways. Maybe, you can give more details about what bothers you reading my answers.
I am not completely sure how the first question is related to REST because I feel it is about wording. The question to me would be: Why is it not allowed to order both of these products together? So, you cannot but them into the same shopping basket? This would not be really user-friendly, so the best idea would be to allow it. If you cannot change that both are not allowed at the same time, I would just "grey out" all the items that are not allowed together with product X if it is already in the shopping basket.
However, this is more of a user experience question. Maybe, you could go into detail here in what exact case a user could be insert both of the products at the same time, while it is not allowed.
Towards your second question: In most online shops you usually have a state that is either mapped to the account, a session or via cookies. If you truly want to have a stateless API here with REST, you could work with order IDs. These could be passed to each request. Of course, the order itself has a state. But the requests do not have one.
Notice: REST does not mean much. You basically have no state for each request and have all information in the URL that are necessary.
Maybe, this helps a bit already.
Is there any way to achieve an atomic transaction using the Rally wsapi. I know a transaction implies state among the consecutive requests, but REST obviously is a stateless protocol. So that might be an issue.
need to be able to pull a portfolioitem/feature and then immediately write it back if I have the most recent version of it. I have a custom field on portfolioitem/feature that WILL be edited by multiple people simultaneously, and I need to make sure that each update happens in the correct order.
Since i don't have access to Rally's server stuff, i must do all this client side, and I can't figure out how to do this. I will be doing this will the Rally SDK also.
I don't think WS API supports atomic transactions. A scenario where updates occur as one atomic transaction so that, for example, if one of the updates fail they are all rolled back is not supported. In the example you mentioned each update will be a distinct transaction and in case of a mid-air collision when the same artifact is updated by different users, one of the users will receive a concurrency error.
I am in the same boat as the OP, the only difference being that hours may pass between the read and subsequent write. Interestingly, I only seem to get concurrency errors when I attempt to update a record while there's another transaction of mine in flight. I don't see any exception raised when I am updating a record using a stale version thereof, i.e. one that someone else has changed from under me.
I will be attempting to fix this soon as it's becoming an issue. The chosen approach is to forcibly chain a GET before every POST, and throw an exception if the VersionID of the record I GET doesn't match the one I have stored in-memory. In case of mismatch, it will refresh the local record (and thus, view) and prompt the user to resubmit their changes. Yes this will be inconvenient for a user but in my app most changes are a single click away so it's reasonable.
I too would like to know if there is a better approach to this problem. One would assume that with every record having a VersionID, it would be handled server-side, with proper support from WsapiProxy on the client end. Maybe I'm missing something obvious, like explicitly fetching VersionID?