I want to call a QBO3 operation asynchronously, using the Queue behavior.
How can I push a method call to a QBO3 queue using the Quandis REST Api and/or Javascript?
Here is the basic pattern for Javascript:
object = new qbo3.{className}()
object.invoke('Queue/{methodName}', { 'QueueName': '{queueName}', ... })
A raw REST call with a URL would follow this pattern:
{domain}/{className}/{handler}.ashx/Queue/{methodName}?{parameters}
Related
I have been working on this problem for a couple of days now, and feel like I'm extremely close to solving the issue. I need to cycle through an object and send a text message to each record in the object before moving on to the next line of code. The code to send works when isolated locally. But I'm having trouble getting it to work in Twilio Functions. All my code appears to work, but the text messages are not sent.
for await (const contact of allItems) {
client.messages
.create({
body: "Hey " + contact.name + "!" + " " + message,
messagingServiceSid: messaging_service,
to: contact.key
});
};
// End Send Message to Each Contact
I've attached the portion of code I believe I'm having issues with.
What I want to do, is for this piece of code to run completely before moving on to the next few lines and invoking a callback.
Any idea how I could do something like this?
Twilio developer evangelist here.
The issue here is that you are not awaiting the actual result of the asynchronous call. Locally, that doesn't matter, but within Twilio Functions once you call the callback function all asynchronous calls that have started are terminated.
To create a loop that makes asynchronous requests and waits for them all to complete you will want to use Promise.all in conjunction with map. In your example, it should look like this:
function SendMessages(allItems, message, client, messagingService) {
const apiRequests = allItems.map((contact) => {
let usersName = contact.name;
return client.messages.create({
body: `Hey ${usersName}! ${message}`,
messagingServiceSid: messagingService,
to: contact.key,
});
})
return Promise.all(apiRequests);
}
In this function we map over the list contacts returning the promise that is created when we try to send a message. The variable apiRequests becomes an array of promises that represent the requests to the API. We can then use this array of promises in Promise.all. Promise.all will only resolve once all the promises it is passed have resolved (or if a promise rejects).
I recommend you read my answer to your previous question as that brings up some further issues that you might have with this.
I would like to send a batch request to the changeset in the backend from my UI5 application. I did the following:
I created an Entity in my segw service. In the "changeset_begin" method I set the cv_defer_mode to true for my Entity.
In the frontend I tried to send a call to the backend. But somehow it doesnt work and I cant set a breakpoint in the ChangeSet. Are my syntax wrong? Thank you very much!
oDataModel.create("/MyEntitySet", { // in a loop, values are changed
properties: {
Key: item[i].getKey(),
Salesorder:"347854"
Department: "HR"
}
});
oDataModel.submitChanges({ // executed after loop
success: function (oData) {
oDataModel.refresh();
}
});
According to the API the method you are looking for is createEntry.
Creates a new entry object which is described by the metadata of the entity type of the specified sPath Name. For each created entry a request is created and stored in a request queue. The request queue can be submitted by calling submitChanges
Currently i have a logic in ServiceWorker where i need to check within Service Worker if a particular event.respondWith() has finished or not , only after that i need to delete the cache.Is there any way to know that.I checked that event.respondWith() does not have a then() or callback .
If your cache cleanup is independent of the Response that's being used to fulfill the Promise passed to event.respondWith(), then you can (probably) just kick it off asynchronously inside the fetch event handler without worrying about whether event.respondWith() has completed. This would be the case if you, for instance, want to clean up a cache whenever it's grown past N entries in size.
If your cache cleanup is specific to the Response that's being used to fulfill the Promise, then you're going to want to insert the logic into the Promise chain, making sure that you end the chain by fulfilling with the valid Response. I'm assuming that you have control over the fetch event handler and can do that. Here's an general (untested) approach:
self.addEventListner('fetch', event => {
const p = promiseThatFulfillsWithResponse(); // Your logic goes here.
event.respondWith(p.then(response => {
return caches.open('my-cache-name')
.then(cache => cache.delete(event.request)) // Or whatever you want to delete.
.then(() => response); // Return response at the end of the chain!
});
});
You don't want to do too much inside your Promise chain, since everything you do will delay the Response being passed to the controlled page.
So as recommended I'd like to use RestSharp to handle REST web service. I am developing iOS and Android application and I would love to make PCL that makes requests to the service and just returns parsed results (eg. array of User objects).
So how do I get RestSharp in my PCL, tried NuGet, components are not for PCLs and seriously bad would be to just download source files and copy them in the project, I want to keep some dependency management in place.
What is the best practice? Am I looking at this problem at wrong angle?
RestSharp doesn't support PCLs. I'd suggest checking out PortableRest, or just using a combination of HttpClient and Json.NET.
I use dependency injection so I can support non-PCL JSON parsers. I also plan to give the native HttpClient wrappers from the component store a try. By using non-PCL code you will gain quite a lot in performance compared to Json.NET etc.
Link to source code
Text library has serializer interfaces, Web has the IRestClient.
Modern HTTP Client from the component store.
Below modifications worked for me and will be glad if it works out to you.
Try using modernhttpclient in your PCL. And inAndroid project ensure you have the below packages.
Microsoft.Bcl.Build
Microsoft.Bcl
Microsoft.Net.Http
modernhttpclient
Along with that in application manifest under required permissions give permissions to the below.
Access_Network_State
Access_wifi_state
Internet
Ideally when you try to add Microsoft.Bcl into your Android project targettting monoandroid it will throw out error, so try to add the nuget refrence in the above order.
I developed a really simple REST client to perform Http requests easily. You can check it on my Github repo. The API is really simple:
await new Request<T>()
.SetHttpMethod(HttpMethod.[Post|Put|Get|Delete].Method) //Obligatory
.SetEndpoint("http://www.yourserver.com/profilepic/") //Obligatory
.SetJsonPayload(someJsonObject) //Optional if you're using Get or Delete, Obligatory if you're using Put or Post
.OnSuccess((serverResponse) => {
//Optional action triggered when you have a succesful 200 response from the server
//serverResponse is of type T
})
.OnNoInternetConnection(() =>
{
// Optional action triggered when you try to make a request without internet connetion
})
.OnRequestStarted(() =>
{
// Optional action triggered always as soon as we start making the request i.e. very useful when
// We want to start an UI related action such as showing a ProgressBar or a Spinner.
})
.OnRequestCompleted(() =>
{
// Optional action triggered always when a request finishes, no matter if it finished successufully or
// It failed. It's useful for when you need to finish some UI related action such as hiding a ProgressBar or
// a Spinner.
})
.OnError((exception) =>
{
// Optional action triggered always when something went wrong it can be caused by a server-side error, for
// example a internal server error or for something in the callbacks, for example a NullPointerException.
})
.OnHttpError((httpErrorStatus) =>
{
// Optional action triggered when something when sending a request, for example, the server returned a internal
// server error, a bad request error, an unauthorize error, etc. The httpErrorStatus variable is the error code.
})
.OnBadRequest(() =>
{
// Optional action triggered when the server returned a bad request error.
})
.OnUnauthorize(() =>
{
// Optional action triggered when the server returned an unauthorize error.
})
.OnInternalServerError(() =>
{
// Optional action triggered when the server returned an internal server error.
})
//AND THERE'S A LOT MORE OF CALLBACKS THAT YOU CAN HOOK OF, CHECK THE REQUEST CLASS TO MORE INFO.
.Start();
Environment: Mac osx lion
Grails version: 2.1.0
Java: 1.7.0_08-ea
If I start up vertx in embedded mode within Bootstrap.groovy and try to hit the same websocket endpoint through multiple browsers, the requests get queued up.
So depending on the timing of the requests, after one request is done with its execution the next request gets into the handler.
I've tried this with both websocket and SockJs and noticed the same behavior on both.
BootStrap.groovy (SockJs):
def vertx = Vertx.newVertx()
def server = vertx.createHttpServer()
def sockJSServer = vertx.createSockJSServer(server)
def config = ["prefix": "/eventbus"]
sockJSServer.installApp(config) { sock ->
sleep(10000)
}
server.listen(8088)
javascript:
<script>
function initializeSocket(message) {
console.log('initializing web socket');
var socket = new SockJS("http://localhost:8088/eventbus");
socket.onmessage = function(event) {
console.log("received message");
}
socket.onopen = function() {
console.log("start socket");
socket.send(message);
}
socket.onclose = function() {
console.log("closing socket");
}
}
OR
BootStrap.groovy (Websockets):
def vertx = Vertx.newVertx()
def server = vertx.createHttpServer()
server.setAcceptBacklog(10000);
server.websocketHandler { ws ->
println('**received websocket request')
sleep(10000)
}.listen(8088)
javascript
socket = new WebSocket("ws://localhost:8088/ffff");
socket.onmessage = function(event) {
console.log("message received");
}
socket.onopen = function() {
console.log("socket opened")
socket.send(message);
}
socket.onclose = function() {
console.log("closing socket")
}
From the helpful folks at vertx:
def server = vertx.createHttpServer() is actually a verticle and a verticle is a single threaded process
As bluesman says, each verticle goes in its own thread. You can span your verticles across cores in your hardware, even clustering them with more machines. But this add capacity to accept simultaneous requests.
When programming realtime apps, we should try to build the response as soon as posible to avoid blocking. If you think your operation can be time intensive, consider this model:
Make a request
Pass the task to a worker verticle and assign this task an UUID (for example), and put it into response. The caller now knows that the work is in progress and receive the response so fast
When the worker ends the task, put a notification in event bus using the UUID assigned.
The caller check the event bus for the task result.
This is tipically done in a web application vía websockets, sockjs, etc.
This way you can accept thousands of request without blocking. And clients will receive the result without blocking the UI.
Vert.x use the JVM to create a so called "multi-reactor pattern", that is a reactor pattern modified to perform better.
As far as I understood is not true that each verticle has its own thread: the fact is that each verticle is always served by the same event loop, but more verticles can be binded with the same event loop and there can be multiple event loops. An event loop is basically a thread, so few threads should serve many verticles.
I didn't use vert.x in embedded mode (and I don't know if the main concept change) but you should perform much better instantiating many verticles for the job
Regards,
Carlo
As mentioned before Vertx concept is based on reactor pattern which means the single instance has at least one single-threaded event loop and processes events sequentially. Now the request processing may consist of several events, the point here is to serve the request and each event with non-blocking routines.
E.g. when you wait for Web Socket message the request should be suspended and in the event of message it is woken back. Whatever you do with the message should be also non-blocking thus asynchronous, like any file IO, networking IO, DB access. Vertx provides basic elements which you should use to build such async flow: Buffers, Pumps, Timers, EventBus.
To wrap it up - just never block. The use of sleep(10000) kills the concept. If you really need to halt the execution use VertX's Timers instead.