Both have same parameter except Get Request have extra one json
Here is one example
Create Session httpbin http://httpbin.org
&{params}= Create Dictionary key=value key2=value2
${resp}= Get Request httpbin /get params=${params}
log to console ${resp.content}
In line 3 get method takes parameter , can we use Get Request and Get method together.I am unable to relate how both method works in line 3
When you call the keyword Get Request after having imported RequestsLibrary, that keyword calls the method get_request that is part of the definition of the RequestsLibrary class. They aren't different, one is just the public interface to the internal method. When robot sees you call the Get Request keyword, it scans the libraries for a method named get_request. The method in the library is then called.
Any parameter that the get_request method takes is perfectly valid when calling the keyword. Again, the keyword and the method are identical. They are exactly the same thing.
Apparently, the json parameter that you are asking about was added fairly recently. I guess either that version of the library hasn't been released yet, or the documentation hasn't been updated.
If the version of RequestsLibrary on your computer has the json parameter, you can use that in your test.
Related
The pprof package documentation says
The package is typically only imported for the side effect of registering its HTTP handlers. The handled paths all begin with /debug/pprof/."
The documentation says if you already have an http server running you don't need to start another one but if you are not using DefaultServeMux, you will have to register handlers with the mux you are using.
Shouldn't I always use a separate port for pprof? Is it okay to use the same port that I am using for prometheus metrics?
net/http/pprof is a convenience package. It always registers handlers on DefaultServeMux, because DefaultServeMux is a global variable that it can actually do that with.
If you want to serve pprof results on some other ServeMux there's really nothing to it; all it takes is calling runtime/pprof.StartCPUProfile(w) with an http.ResponseWriter and then sleeping, or calling p.WriteTo(w, debug) on a runtime/pprof.Profile object. You can look at the source of net/http/pprof to see how it does it.
In a slightly better universe, net/http/pprof would have a RegisterHandlers(*http.ServeMux) function that could be used anywhere, you would be able to import it without anything being registered implicitly, and there would be another package (say net/http/pprof/sugar) that did nothing except call pprof.RegisterHandlers(http.DefaultServeMux) in its init. However, we don't live in that universe.
We have an NServiceBus 6 environment with a number of services that send files between each other using DataBusProperty over a custom SqlDataBus : IDataBus.
This works fine on NSB6 using the built in JSON serializer, but is now broken after we moved to NSB7 and the NewtonsoftSerializer.
Removing DataBusProperty from our classes and just using byte[] works fine. We also tried changing the DataBus to FileShareDataBus but got the same exception:
NServiceBus.MessageDeserializationException: An error occurred while attempting to extract logical messages from incoming physical message c7b5cd47-c1b7-4610-9f6c-aa7800cc9b64 --->
Newtonsoft.Json.JsonReaderException: Error reading bytes. Unexpected token: StartObject. Path 'Data.Key', line 1, position 68.
This fails even if a service is sending messages to itself. Also we can see the files written to the file store, whether on Sql or File Share, so they're serializing fine.
An example payload from the error queue is
{"ExecutionId":"1db85105-a71c-4b29-87da-9b7ae6518c1c","Data":{"Key":"2019-06-26_13\\6a2b63c7-12b0-46dd-8b92-f1fc743d27c1","HasValue":true}}
How can we get this to deserialize in NSB7+NewtonsoftSerializer when it works fine in NSB6+JsonSerializer?
Thanks
I just spent about 8 hours trying to figure out what was going on, and realized, that for whatever reason, NSB7 wants a paramaterless constructor and settable properties. I am going back to Particular to see if this change is expected, but I expect we will have to adjust all of our message classes to fit that paradigm.
Although data bus properties should work there is also an alternative to data bus properties which is using stream attachments via send options:
https://docs.particular.net/nservicebus/messaging/attachments-sql
Depending on the use case using Streams might be a more efficient approach.
I have a D-Bus method that takes a QDBusUnixFileDescriptor as a parameter. But I do not know how to call this method via the bus.
The documentation for QDBusUnixFileDescriptor states:
This allows applications to send and receive Unix file descriptors over
the D-Bus connection, mapping automatically to the D-Bus type 'h'.
To call other methods I am using QDBusInterface::call which takes the method name and a bunch of QVariants. QVariant is not implemented for QDBusUnixFileDescriptor.
I've been unable to locate any examples either in Qt documentation, at github, or with google.
How can I call a bus method that takes a QDBusUnixFileDescriptor as a parameter?
I am rather new in Qt, but as good as I know you can check
QVariant::fromValue(yourQDBusUnixFileDescriptor)
Good luck
Is it possible to restore a 1:1 conversation?
The Conversation object in the Skype SDK seems to have such functionality. You should be able to restore a conversation by passing a href to it. But when I pass a href string as parameter to createConversation it throws the following error:
Error: ResourceNotFound
at Error (native)
at Exception (http://.../SkypeSDK.js:3346:31)
at UCWA.get (http://.../SkypeSDK.js:15141:31)
at init (http://.../SkypeSDK.js:40672:50)
at new Conversation (http://.../SkypeSDK.js:41826:25)
at createConversationModel (http://.../SkypeSDK.js:41963:36)
at BaseModel.createConversation (http://.../SkypeSDK.js:42037:48)
The lines can be a little bit off. I modified the createConveration method to pass the href to Conversation.
The href string has this format:
/ucwa/oauth/v1/applications/xxxxxxxxxxxx/communication/conversations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
We have the following situation:
One site has the normal SDK and waits for incoming calls. If you accept the call you should be redirected to a site with the SDK+CC and answer the call. Now we are stuck at how to pass the call. We also tried with it getConversation, but it doesn't return the last incoming conversation.
Once you accept a call on one endpoint you can transfer it to another endpoint. However you cannot accept a call and then re-answer it on a different endpoint. Also, answering the call starts the process of connecting media so that endpoint has effectively picked up the call.
The href of each conversation is unique per application, and in your scenario you will have one for each site. These cannot be shared between applications.
For a user application (not a driver) using WinUSB, I use WinUsb_ControlTransfer in combination with overlapped I/O to asynchronously send a control message. Is it possible to cancel the asynchronous operation? WinUsb_AbortPipe works for all other endpoints but gives an 'invalid parameter' error when the control endpoint is passed (0x00 or 0x80 as the pipe address). I also tried CancelIo and CancelIoEx but both give an 'invalid handle' error on the WinUSB handle. The only related information I could find is on http://www.winvistatips.com/winusb-bugchecks-t335323.html, but offers no solution. Is this just impossible?
Probably not useful to the original asker any more, but in case anyone else comes across this: you can use CancelIo() or CancelIoEx() with the file handle that you originally passed in to WinUsb_Initialize().
This is similar to how the documentation of WinUsb_GetOverlappedResult says:
This function is like the Win32 API routine, GetOverlappedResult, with one difference—instead of passing a file handle that is returned from CreateFile, the caller passes an interface handle that is returned from WinUsb_Initialize. The caller can use either API routine, if the appropriate handle is passed. The WinUsb_GetOverlappedResult function extracts the file handle from the interface handle and then calls GetOverlappedResult.