I need to make custom error messages based on the error message that I get back from chase/merchant.
The problem is, there's so many merchants/banks that use different error codes.
What's a solution for this? Is there anything more simple than making a database to handle all types of error codes?
Example
Wrong CVV entered
Costco Mastercard returns error code 522
Walmart Mastercard returns error code 702
SELECT ERRORMESSAGE
FROM ERROR_MESSAGE_TABLE
WHERE ERRORCODE = #ERRORCODE
Sorry I guess this is a very broad question looking for ideas instead of just straight answer technical help. Not sure where to ask my question.
One of the principles of SOA is that you never expose the internal of a provider to the consumer. Or in other words you don't tightly couple/bound your service provider and consumers with each other.
If for example Merchant A has an error message 100-wrong pin entered and you expose this error to your consumers/clients they are now tightly bound to merchant A.
If merchant A decides to change the error message (they upgrade their system which will happen) from 100 to BADPIN: Bad pin entered then all your consumers has to change. It is important that you abstract these details away from your clients/consumers. This will shield them from changes on you side.
So yes create a table with the merchant errors codes and your own errors code in and map these to each other. You consumers only have to worry about your codes then.
Hope this makes sense I can demonstrate with an example if you need it.
Related
We have adopted an AWS powered microservice architecture where different sorts of payloads enter the system with a UUID and type via mysql.lambda_async from our database.
The problem is, that we've noticed that messages can come out of order. Imagine the scenario with the following type of message:
DEASSIGN_ROLE
ASSIGN_ROLE
When the actual intention was a quick toggle:
ASSIGN_ROLE
DEASSIGN_ROLE
Now we have a user with the wrong (elevated) permissions.
I've done some cursory research and for example answers like Handling out of order events in CQRS read side suggest using sequence numbers.
Introducing a sequence number would be quite hard as we have many different types of messages. A sequence number would require a syncronous counter, where we have gone great pains to be simply asynchronous. Bear in mind, our system that generates the message is an SQL trigger ultimately.
Are there simpler solutions I am missing?
I would say there is an unsolvable problem :
you want to be full asynchronous
you need sequentiality in your results
We had the same problem as yours, and we ended by setting sequences by type of messages.
Trying to be asynchronous and parallel when possible (according to message types/topics)
Recently, my application started to generate a new error whenever a customer uses it to like a post/comment. We use the graph API to create and destroy likes:
https://graph.facebook.com/POST_ID/likes
But we get a status 400 with the following body upon a POST:
{"error":{"message":"You've been blocked from using this feature because you may have violated Facebook's Terms. Please review the Community Standards to learn what's acceptable to share on Facebook.\n\nIf you need help, please contact us.","type":"OAuthException","code":368}}
To be honest, it is hard for me to understand what my customers might have done to deserve this and I can't find any obvious way to "contact us". Is there someone who knows what might trigger this kind of error and what I could do to help my customer resume normal operation ?
Mathieu
I did a search on the board and there were some threads related to what I will ask but the other questions were not exactly like my situation.
I want to implement a service (ejbs) and different clients (rest api, webservice, jsf managed beans and maybe some other client) are going to use this service. My question is: in this scenario, where should data validation occur?
Seems reasonable to me to do it inside my business control (ejbs),- since I don't want to implement one validator type for each client- but I don't see people doing it...
best regards,
Oliver
The general advice would be: Every component, which exposes functionality to the outside should validate the input it receives. It should not hope for the best that it will in all cases receive valid input. Additionally, as you said, it keeps the validation at one place.
On the other hand it may be a reasonable decision when you have both sides under your control to decide for an early validation on the client and document the expected/required valid input data.
You have a similar problem when designing a relational database structure - you can have all sorts of constraints to ensure valid input data or you can check validity in the component storing the data in the database.
And, not to forget, whenever you validate in a deeper layer, all higher layers have to handle the exceptions or error messages when validation fails.
Regarding your specific question, the usage of the same service from different clients advises to validate within the service.
What I am looking for is a tool that easily or automatically sends coldfusion error messages to their system.
Then I can use the web-based interface, to manage priorities, track who fixed what and so forth.
But I want to use this to help us deal with errors better, but also to show the importance of a bug tracking system to my fellow works.
System Requirements: Apache, Windows, Coldfusion 8 Standard, Sql Server 2005.
Financial Requirements: Free or Open Source
Goal Or Purpose: To encourage my fellow workers to want and use a bug tracking system.
Does this re-write make more sense?
Thanks
Craig
Wiki has a list of issue tracking software, maybe this list could help.
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
You may be able to find a hosted service and use either email or web services to create the ticket using onError. With that said, a simple issue tracking app could be created for your site using the same DB used to drive the content. 2 or 3 tables would take care of the data storage and you're already using CF so the application layer is already there.
HTH.
I have been heavily using this type of a setup for several years by email only, and the last 3 years with a Bug Tracking Software.
I must say, the bug tracking software has made my life so much more peaceful. Nothing is left, forgotten, or slips through the cracks. It's easy to find trends in errors, and remember "all the times" it happened.
Our setup is like this:
1) Coldfusion + Appropriate framework with error reporting - It doesn't matter what you use. I have used Fusebox extensively and am making the transition to ColdBox. Both are very capable, in addition to Mach-II, FW/1, Model-Glue, etc. The key part you have to find in them is their ability to catch "onError", usualy in the application CFC.
2) Custom OnError Script - Wherever an error occurs, you want to capture the maximum amount of information about that error and email it in. What we do is, when an error occurs, we log the user out with a message of "oops, log in again". Before logging them out, the application captures the error and emails it to Fogbugz. Along with it, at the top we include the CGI variables for the IP address, browser being used, etc. Over time you will find the things you need to add.
3) Routing in Fogbugz. A 2 user version of Fogbugz is free, and hosted online. There are two main ways to submit bugs. One is to email one in at a time. So if an error happens 2000 times, you get 2000 emails, and 2000 cases. Not always the best to link them together, etc. They have a feature called BugzScout, which is essentially an HTTP address that you do a form post to with cfform with all of the same information you would have put into the email. There's plenty of documentation on this and something I've always wanted to get around to. I had a scenario of 2000 emails for the first time happen a few weeks ago so I'll be switching over to this.
Hope that helps. Share what you ended up doing and why so we all can learn too!
I'm surprised no one mentioned LighthousePro (http://lighthousepro.riaforge.org). Open source - 100% free - and ColdFusion. As the author I'm a bit biased though. :)
Hard question to answer not knowing what kind of restrictions are there? Do you have any permissions to install anything? Also most bug-tracking systems require some kind of database support.
I have a suggestion. You can put in place a basic bug-tracking system, that just allows people to create tickets, and allows you/someone else to close it.
More Windows based tools are mentioned here
Good open-source bug tracking / issue tracking sofware for Windows
Any reason why coldfusion specifically?
I really like Fogbugz from the makers of Stack Overflow. For one user it's quite reasonably priced. I enter some bugs manually and have others emailed in.
A lot of bug tracking software will expose SOAP methods for entering data into them.
For example, we used Axosoft's OnTime and that exposed some WSDL pages that I consumed in my application. I was told that Jira did as well.
There are few in CF411 list: Bug Tracking/Defect Tracking/Trouble Ticket/Help Desk Tools Written in CFML
We use HopToad. There is another bug-tracking app called LightHouse that integrates with HopToad so you can easily create a [bug] ticket from an incoming exception. HopToad has an API of which there are many clients, you want the CF based one:
http://github.com/timblair/coldfusion-hoptoad-notifier
Even if you dont use HopToad and you end up using a different service or roll your own, if you needed to write your own API client you could leverage the code or pattern(s) of the above HopToad client.
A lot of good information from everyone, and I really do appreciate the efforts given. But not the answer i was looking for. Which maybe means, that what i want does not exist, yet.
So i may have to roll my own solution...Or maybe integrate with another existing app...
Thank You all.
The project that we worked on consists of 3 tiers: the presentation tier, the business logic tier and data tier, I will call them here the front, mid and back.
The front is written in PHP and it communicates with the mid via web service (XML-RPC, SOAP, etc.). Users can also write their own clients to talk to the mid. The nid is developed in Java, it performs business logic and provides data to the front, it may also throws exception to the front.
The question I am having is, if I want to have multi-lingual support in future, where shall I develop i18n? It makes sense to be at the front because of all the texts that it has, what about exception and other messages coming from the mid?
If a user develops their own client and the mid has multi-lingual support, the messages coming from it (like exception as said above) can therefore be in their selected language. That's the advantage I'm seeing. I just don't like the idea of having two layers with i18n code and having to handle i18n when I am handling an exception.
It depends a lot on your application.
If you think UI localization, the presentations is definitely affected.
I would say that the middle tier should not generate any messages.
Exceptions are intended for developers, not for users. So in the presentation capture the exception, and present it to the user in a localized way saying something like "Fatal error 12313 occurred, please send this report to ..."
(maybe even nicer, you don't show the exception text at all, offer a "Send a crash report" button, with a "Show report" button for the user to see that you are not sending any private data).
But if you thing about stuff beyond UI, then the others might also be affected.
The business logic might be affected (for instance the way the tax systems work are different from country to country). And that is independent of the UI (Canada or Australia have another tax system than US, even if the UI is still English).
So you might want to design this layer very modular.
The content of the database might also be affected. Imagine you have products that are not available (or are banned) in certain countries. So you might need extra fields (or tables) to carry that info.
So in the end the answer is "you have to think about i18n at every level!" and ask yourself "what if"
I would ask you a question: The i18n data would be handled in the back layer (data tier)?
If you say yes then you got it, but if you say no then I would put it in the mid layer (busieness tier) because medium and larger projects use to interact with I18N (exceptions, currencies, message formats, time zones, charsets, etc...)
I would put it in the front layer (presentation tier) for smaller projects.
Regards.
If you want to be completely internationalized, exceptions and other messages from the middle-tier should not include text. You should specify a code that the client must look up in a table to understand.