I have started learning about NServiceBus to determine whether we can use NServiceBus the way we want.
When I configured NServiceBus to use the JsonSerializer for serialization, I expected to be able to read the contents of the messages directly in the queue. But instead of being JSON formatted text, the body is hexadecmial. We would like to be able to open up a queue/table and view the contents of the messages without needing to convert every message from hex to text. Is this possible?
PS.: I am using NServiceBus v 5.2.14 and NServiceBus.Host v 6.0.0
There are several options:
MSMQ
For MSMQ I honestly believe the best option would be to use ServiceInsight. It gives you much more than just viewing the message payload but if you're in a position that you need to know why your system is behaving the way it is, this is the best option.
Regarding native tools for MQMS there are several options http://docs.particular.net/nservicebus/msmq/viewing-message-content-in-msmq
SQL Server Transport
While ServiceInsight works across all the transports, if you are using the SQL Transport and you just want to see content of your messages you can run a simple SQL query query:
SELECT CONVERT(VARCHAR(max), [Body]) FROM [YourQueue]
Having said that, you are technically converting message to text through this query.
Related
I'm trying to parse the last received message from Pushbullet. I'm currently doing it using Clicks, which means that I do every single clicks, sendkeys and all the rest needed actions automatically. In other words it is just a simulation of the user. One of the biggest con of the method is that whenever xpath or a class or id of the element changes which I'm aiming with Selenium, whole cycle fails and the test case can not proceed operating.
I want to change the way I'm doing. Particularly, I want to send a json request to Pushbullet API and then get the response in return.
I just couldn't decide from where and how to start doing.
Could you guys please tell me the way from where should I start and what are the steps that needs to be covered in order to finally reach the finish line?
Thank you in advance.
I noticed that this question is tagged under Selenium, but in your question, you express interest in switching to an API approach. I will try to provide some advice to you on this.
Selenium Approach
You mention that you tests are brittle, and if anything changes then they fail. This is usually the case with UI tests. If you would like to stick with the Selenium approach, I can try to help you write more robust locators for your WebElements that will not break constantly.
API Approach
You will need to start with the Pushbullet API documentation -- https://docs.pushbullet.com/
To get messages, it looks like you will want to use the chat endpoint -- a sample request looks like this: https://api.pushbullet.com/v2/chats, plus authentication.
Once you fetch the chat objects, you will need to write your own logic to parse each chat object and fetch the most recent message from there.
Depending on what language you are using, you will need to install a REST client package onto your project. I use C#, so RestSharp is the client I like to use.
I recommend installing a REST client interface, such as Postman, to start practicing your API calls. Once you get your API calls working in Postman, you can start writing code to make these API calls.
What other questions do you have about this?
I'm working on a codebase that attempts to make a REST call to a remote service, which returns JSON. The call works fine when it gets normal JSON back. In some cases, like when the network blows up, it gets back HTML, which tries to report various network problems.
Our error handling code in the client needs to deal properly with this situation, which is defined as simply obtaining the HTML string and logging it.
I find it's a little hard to write an automated test for this.
In our client code, we use ClientBuilder.newBuilder()... , then call "build()", which returns the Client, and then we call "client.target(url)" and then move forward with getting the response. We have an exception handler that will attempt to read the raw text.
In a test for this kind of thing, I'm used to using the CXF JAXRSServerFactoryBean class to run a server. I know how to connect the client to the server, but I'm not sure what to configure in the server to allow me to return arbitrary text, instead of a "resource class".
It's also possible that using JAXRSServerFactoryBean is overkill for this, as it just needs to return plain text.
What are my options here?
Update:
I did make progress setting up a test using JAXRSServerFactoryBean, but I'm still wondering if there are other options, especially ones that mitigate the next problem that I discovered, described at Using javax.ws.rs.client.ClientBuilder in CXF to create Client, any route to be able to use local transport? .
Update:
I gave up on the JAXRSServerFactoryBean approach, as I don't need to test the network, and doing so adds additional complications. The JAX-RS filter approach is simpler and avoids those complications. See the above linked question for details.
I have an API that produces JSON like this:
)]}',
{
//JSON DATA
}
The //JSON DATA is valid JSON, but the )]}', up top is not.
When I try to GET this data via a Logic App, I get:
BadRequest. Http request failed: the content was not a valid JSON.
So, a few related questions:
1) Can I tell the logic app to return the invalid JSON anyway?
2) How can debug the issue better? I happen to know that the response is invalid, but what if I didn't? Can I see the raw data somewhere?
3) This is all done via the Azure web portal. Are there better tools? Visual Studio?
I should also mention that if I call a route on the same API that returns XML instead of JSON, then the Logic App works fine. So it definitely doesn't like the JSON response in particular.
Thanks!
First of all, please do not post three questions as a single question.
Question 1). The best thing you can do is make the API return a valid JSON object. This is good for million reasons. Here're a few:
it's pretty much a standard (either valid JSON or XML -- yeah, old school way);
therefore, no users of this API (including you) will need to struggle and guess what's going on and why;
your Logic App's step will just work without adding extra complexity;
you will make this world and your karma better.
If API-side changes are not within your reach, I don't think you can do much. If you're lucky and the HTTP action is successful (Status Code 2xx), you can try to use a Query Action with a function that truncates the first characters. It will look something like this (I don't know the exact syntax): #Substring(body('myHttpGet'), 4, length(body('myHttpGet')) - 4) where myHttpGet is the id of the Http Get action.
However, once again, if possible, I strongly recommend fixing up the API which is the root cause of the problem, instead of dealing with garbage response after that.
UPDATE Another thing you can do is wrap the dirty API. For example, you could create a trivial Azure Function that invokes the API you don't directly control, and sanitizes the response for you consumption requirements. This Azure Function function should be easy to call from the Logic App. It costs almost nothing (unless we're talking millions of requests/month). The only drawback here is the increasing latency, which may be not an issue at all -- test it and see whether it adds less than 100ms or so... Oh, and don't forget to file a ticket with the API owner, they make our world a bad place!
Question 2) In Azure Logic App web UI you can Look into the execution details and the error will definitely be there.
Question 3) You're asking for a tool recommendation which is by definition a highly subjective thing and is off-topic on StackOverflow.
TL/DR: The other app is not producing valid JSON.
Meaning, this is not a problem for you to solve. The other app has to return valid JSON if the owner claims it should.
If they cannot or will not produce valid JSON, then the first thing you need to do is inform your management that you will have to spend a lot of extra time accommodating their non-standard format.
I am writing a web service in node, and testing it with Postman. I spent a long timing looking for an error. When I finally found it, it turned out to be a simple error formatting the response body, which is json.
If I leave off the final brace in the response body, Postman waits for two minutes, and then reports that it received everything, just fine.
If I leave off the closing quote in the last value in the json, Postman says the server didn't respond, perhaps I should check my security certificates.
I would much rather Postman said "Hey, Buddy, you left off a quote!"
If there some validation service I can talk to? Or a plugin in Postman?
Here there are some validation javascript libraries, you can use:
Validator provides a declarative way of validating javascript objects.
Express-validator acts as an express.js middleware for node-validator.
Meanwhile, Postman got API testing and Collection Runner that can help you through this; which you can write some pre-request script as well as test script for each request.
Also, they got Newman which is a command-line collection runner. It allows you to effortlessly run and test a Postman collection directly from the command-line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems.
I found that Paw worked (https://paw.cloud/). And so far I haven't paid for it.
Where Postman said "check your security certificates," Paw said "we were expecting 376 bytes but you only sent us 312."
Cuts down my time solving the problem a lot!
I use Fiddler for this. It is very good at identifying (with an error message that pops up) problems and bad implementations of the HTTP protocol. Browse the web with it running, and within a few minutes you'll undoubtedly hit a poorly implemented server.
Postman won't be able to handle these cases since it's insulated from poor behavior by the browser's framework.
That's not your problem though.
When I finally found it, it turned out to be a simple error formatting the response body, which is json.
That has absolutely nothing to do with HTTP. HTTP doesn't know or care what your request/response bodies are.
The problem you face is that your API endpoint could be returning whatever it wants. You need a custom solution to your problem, as there is no standard API server in this case.
Most folks will run unit tests that hit common endpoints of your service to ensure they're alive and well.
I should also point out that it should be all but impossible for you to break the JSON response if you're doing it correctly. Sounds like you're serializing JSON manually... never do that, we have JSON serializers for this purpose. Send in an object and let it worry about building the JSON output for you. Otherwise, you'll waste a lot of time on problems like these.
I have a simple RESTful web service and I wish to test the PUT method on a certain resource. I would like to do it in the most simple way using as few additional tools as possible.
For instance, testing the GET method of a resource is the peak of simplicity - just going to the resource URL in the browser. I understand that it is impossible to reach the same level of simplicity when testing a PUT method.
The following two assumptions should ease the task:
The request body is a json string prepared beforehand. Meaning, whatever is the solution to my problem it does not have to compose a json string from the user input - the user input is the final json string.
The REST engine I use (OpenRasta) understands certain URL decorators, which tell it what is the desired HTTP method. Hence I can issue a POST request, which would be treated as a PUT request inside the REST engine. This means, regular html form can be used to test the PUT action.
However, I wish the user to be able to enter the URL of the resource to be PUT to, which makes the task more complicated, but eases the testing.
Thanks to all the good samaritans out there in advance.
P.S.
I have neither PHP nor PERL installed, but I do have python. However, staying within the realm of javascript seems to be the simplest approach, if possible. My OS is Windows, if that matters.
I'd suggest using the Poster add-on for Firefox. You can find it over here.
As well as providing a means to inspect HTTP requests coming from desktop and web applications, Fiddler allows you to create arbitrary HTTP requests (as well as resend ones that were previously sent by an application).
It is browser-agnostic.
I use the RESTClient firefox plugin (you can not use an URL for the message body but at least you can save your request) but also would recommend curl on the command line.
Maybe you should also have a look at this SO question.