We are currently using botframeworkAdapter.processActivityDirect to process MS Teams activity from webhook. However, botframeworkAdapter is deprecated and it is recommended to move to CloudAdapter.
I'm having trouble figuring out how to migrate to CloudAdapter because it seems like there isn't a way to process activity without http request and response object. We are processing activity asynchronously through job queues and workers so we don't have access to the original request.
BotframeworkAdapter allows this through processActivityDirect. Wondering if there is a way to achieve this somehow with CloudAdapter. I made a feature request in botbuilder-js repo but just asking in case anyone has ideas.
CloudAdapter.process seems to be the only way to process activity, which seems limited number of options compare to BotframeworkAdapter.
This issue is being addressed here - https://github.com/microsoft/botbuilder-js/issues/4349 where a PR has been raised to Add new method to expose same functionality as BotFrameworkAdapter.processActivityDirect.
Related
I've been following this tutorial and have reached the point where I am able to receive push notifications (only working with android for now). My code is almost identical to the tutorial's. I'm now looking to expand the functionality. In the tutorial, when the app receives a RemoteMessage object, it parses out the "action" value from the data. It then passes that string to the NotificationActionService which triggers an action.
public override void OnMessageReceived(RemoteMessage message)
{
if (message.Data.TryGetValue("action", out var messageAction))
NotificationActionService.TriggerAction(messageAction);
}
The downside to this is that the only information it passes to the rest of the program is the name of the action. I want to add additional information. I would usually just add another parameter to the TriggerAction method, but the implementation of INotificationActionService is pretty involved. I'm wondering if its like that for a reason, or if I can just process my message in the OnMessageReceived. What makes me hesitant to change this is that the this action string is also pulled from the Intent on start up, and I'm not sure if if this will break it. I'm not entirely sure how android intents work, but both the RemoteMessage and the Intent would require this extra data inside the dictionary.
So, what is the best way to modify this tutorial to allow extra context to be passed in the push notification?
This is a good question - and realistically there isn't really one answer. Basically, all Android applications are going to be a collection of Activities and Services. You can think of them like independent threads that the OS is aware of and can help manage. Intents are a standardized way to communicate between these threads using a small set of types that are safe to serialize, so the OS can make stronger guarantees about the how and when it'll be delivered. There's a lot of documentation, and a whole world of different ways to architect your application with these. Each approach will have pros and cons, with some options being way too sophisticated for some applications, and others way too simple.
The Xamarin sample you're referencing keeps two separate threads: one for receiving remote notifications and one for rendering notifications. In principle, a developer may do this to allow notifications to be rendered in response to a message from a remote service OR in response to events local to the phone. For instance, my banking app alerts me that I'm being logged-out after 15 minutes of inactivity, and also when new tax documents are available. The first scenario is best served locally, where a notification will be rendered because a timer reached 15 minutes without being reset. The second scenario is better served by a remote notification so the app doesn't need to poll for new documents.
Bottom line - the sample app may be using an approach that introduces more overhead than your scenario calls for. For others it will be too simple. Choose what is right for your application.
So when I submit a braintree order for settlement, there will/can be multiple state changes until I get my money. It can settle, stay in settling, get declined, and so on.
How can I get this information without having to call their API constantly? Is there some kind of webhook for that? Because in my tests, I only get updates for disbursements, which is (if I understood it correctly) basically the last step of the whole transaction.
There are webhooks for some events, but not for specifically when a transaction changes status.
You can, however, use the Search API to create a script or cron job that checks for status changes over a period of time.
If you have additional questions about webhooks or using the API, contact Support.
Scenario:
I have a call being made to a WCF service which will take several minutes to get a response.
Initially the call was being made with an action which was on the ViewModel which then saved an updated version of an object to a Repository and then the Repository would pass the object to the service layer to be sent to a web service.
Once done the service layer would return the response to the repository and then to the ViewModel which would then raise a dialogue to the user giving them a series of options.
Issue:
The user can goto other views in the app while they are waiting which would destroy the ViewModel which then the user would not get the message alerting them..
So in a nut shell, I need to keep whatever function receives the response from the repository in memory until its completed.
To get around this I moved the dialogue and function into the repository as this is a singleton so will stay in memory but that defeats Single Responsibility as the repositories should only be responsible for the providing of data not carrying out business logic.
I have looked into raising this through messaging centre instead but I believe that this will keep ViewModel in memory and the user could make this request a few times resulting in the messaging center being called with each request.
Does anyone have a best practise for handling this scenario or any documentation they could refer me to?
Thanks for your help in advance :)
In this case you should take a look at background task. It lives outside the lifecycle of mobile app. If your process is taking several minutes it's almost impossible to relay on app itself as user can terminate it or put it to sleep anytime, and you are not able to prevent it.
I have an application which allow an user to send a lot of SMS to his contacts (like thousands).
Obviously that tasks can take a lot of time to complete.
So the idea is to display a progress bar on the client side, to indicate the user how many messages have been sent so far.
The back end of my app is a restful spring webservice.
The front end is done with ReactJS and Redux.
The question is:
Is it technically possible from the back end to periodically push data to the client, to update the progress bar, with the amount of messages already sent.
First question regarding the back end architecture:
I've seen that using JAX-RS 2 with spring, I can make asynchronous call in the back end, to execute other tasks(like querying the DB to see the messages already sent) while the other process is sending all messages. Am i looking in the right direction here ?
Second question regarding front end :
So far I use thunk functions for my requests(post/get) to the server, which returns a json response, and it works well. But in this case, the back end would periodically push data to the client side, until the main task is completed, so I don't understand how would that work out exactly ?
I guess I'm not gonna be able to achieve that using the same request ? Should I look at other technologies to achieve that ?
Please let me know, if the description of my problem is not clear.
Cheers
There are two options: you can keep track of the task on the backend and have an API endpoint to check the status and poll it every x seconds.
The other option would be to use sockets, the frontend client would listen for an event and update display onEvent. The backend would be responsible for emitting events.
Let suppose the following simple UC based on a CQRS architecture:
We have a backend managing a Business Object, let says a Movie.
This backend is composed of 2 Microservices: a CommandManager (Create/Update/Delete Movie) and a QueryManager (Query Movie)
We have a frontend that offer a web page for creating a new Movie and this action lead automatically to another web page describing the Movie.
A simple way to do that is:
A web page collect movie information using a form and send them to the frontend.
The frontend make a POST request to the CommandManager
The CommandManager write the new movies to the datastore and return the movie key
The frontend make a GET using this key to the QueryManager
The QueryManager looks for the Movie in the Datastore using the key and return it.
The frontend deliver the page with the Movie Information.
Ok, now I want to transform this UC in a more Event Driven way. Here is the new flow:
A web page collect movie information using a form and send them to the frontend.
The frontend write a Message in the BUS with the new movie information
The CommandManager listen the BUS and create the new movies in the datastore. Eventually, it publish a new message in the BUS specifying that a new Movie has been created.
At this point, the frontend is no more waiting for a response due to the fact that this kind of flow is asynchronous. How could we complete this flow in order to forward the user to the Movie Information Web page? We should wait that the creation process is done before querying the QueryManager.
In a more general term, in a asynchronous architecture based on bus/event, how to execute Query used to provide information in a web page?
In addition to #VoiceOfUnreason's answer,
If the two microservices are RESTFul, the CommandManager could return a 202 Accepted with a link pointing to the resource that will be created in the future. The client could then poll that resource until the server responds with a 200 OK.
Another solution would be that the CommandManager would return a 202 Accepted with a link pointing to a command/status endpoint. The client would poll that endpoint until the status is command-processed (including the URL to the the actual resource) or command-failed (including a descriptive message for the failure).
These solutions could be augmented by sending the status of all processed commands using Server Sent Events. In this way, the client gets notified without polling.
If the client is not aware that the architecture is asynchronous, a solution is to use an API gateway that blocks the client's request until the upstream microservice processes the command and then to respond with the complete resource's data.
At this point, the frontend is no more waiting for a response due to the fact that this kind of flow is asynchronous. How could we complete this flow in order to forward the user to the Movie Information Web page? We should wait that the creation process is done before querying the QueryManager.
Short answer: make the protocol explicit.
Longer answer: a good place to look for inspiration here is HTTP.
The front end makes a POST to the origin server; as a result the origin server places a message on the queue and sends a response back.
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
The client can then poll the endpoint to find out what progress has been made.
For instance, the endpoint might be a query into the data store, that looks for evidence that the command manager has processed the original command; or it might be an endpoint that is watching the bus for the MovieCreated message, and changes its answer based on whether or not it has seen that.
It may help clarify things to look into idempotent request handling; when the Command Manager pulls a message off of its queue, how does it know if it has previously processed a copy of that message? Your polling endpoint should be able to use the same information to let the consumer know that the message has been successfully processed.
In addition to #Constantin Galbenu's answer, I would like to put in my two cents.
I would strongly advise you to look at a microservices pattern called "BFF" (Backend-For-Frontend) pattern. Instead of having a thick API gateway doing all the work, you can have an API per use-case. For Example: In your case, you can an API called "CreateMovieBFFHandler" which would receive the POST request from front-end and then this guy would coordinate with other things in the system like message queues, events etc. to track the status of the submitted request. UI might have a protocol with this BFFhandler that if the response doesn't come back in X seconds, then the front-end would consider it as failure and if this handler is able to get a successfully processed messaged from message queue or "MovieCreated" event for this key, then it could send a 200 OK back and then you can redirect the page to call write side and then populate the UI.
Useful Link: https://samnewman.io/patterns/architectural/bff/