Been moving into some task oriented UI as a part of my CQRS implementation.
The problem is I have come across the need to update additional properties in my UI as a result of a change made by an initial command sent from the same UI.
My case is different but here's an example...
eg. CommandA Add item to cart resulted in the following events (which all need to be reflected on the UI)
change to store inventory
add item to shopping cart
change total with sales tax
What's the best way to handle this without baking my business logic into my UI?
return a list of resulting events that were performed as a result to the initial command?
return a DTO that reflects changes
other ideas?
I haven't completed it yet, but my idea is to use a Hub from the SignalR framework and subscribe to events and act on them. As long as you can correlate user guids with the connected user guids in SignalR, you can send updates to the correct client and even detect if they still are there.
SignalR isn't that mature yet but the tests I have done works pretty good.
I use it with Knockoutjs and I just update my view models and call functions.
Do those events really need to be reflected in the UI? Consider Amazon, who display "you just added foo to your cart", but don't show any of those other details. That might save you from the problem by redefining it away.
Otherwise, why are you afraid of business logic in the "UI" - specifically, why not include some components from the service that owns each part of that system in your client, and give them the responsibility of doing whatever local updates are appropriate?
In other words, having part of the logic from your sales tax service running in the UI is fine. You (obviously) don't trust it with the billing calculations for tax, but you can totally trust it to do the right thing for the client.
The other advantage of that model is that you get instant feedback for the user, or at least the option of showing instant feedback, without baking more business process knowledge into the client.
For example, recalculating shipping takes time to do - if your client shows a spinner over that, something needs to know to trigger that showing up, right?
If your UI knows that, it has embedded business process around the process. On the other hand, if you have code that is part of the "shipping" service, you can change what response occurs in the client by changing only the one service...
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.
Intro
Hey, my question is kind of hard to explain so I apologize in advance.
Question
I'm trying to implement microservices for our ecommerce and I'm having issues on how to respond to a request when the actual logic and data needs to be determined by other ( 2-3 ) services.
In order to make it easier to understand, I'll give an example.
Lets say User A is trying to buy a product. after clicking on "check out" button these steps should happen.
Flow
Request comes in:
Ecommerce service:
Check if product has enough quantity in inventory.
Publish an event indicating a new order has been created. order:created
Anti Fraud service:
Receives order:created and checks whether the user is a fraud or not
Publishes an event indicating the check was successful. check:succeed
Payment Service:
Receives check:succeed and creates a url to the gateway.
Sends the gateway url to the user. (( this is where the question arises ))
Since all of these steps are asynchronous, how do I respond to the request?
Possible Solution
After the user has requested to checkout, the ecommerce service creates an order and responds immediately with the orderId of newly created order, on client-side the user has to request periodically and check whether the status of order is PENDING PAYMENT, in order to achieve this, the payment service needs to publish payment:created after the order has been approved by the system and then ecommerce service can update the order.
My solution works, but I'm really new to microservices and I want to ask from experts like you on how to implement this in a better way.
I really appreciate if you read this far, Thank you for your time.
your flow is a synchronous process. you need a result from previous step so it has to go step by step.
point of system view:
what matters here is: "how to handle steps?". which reminds me SAGA design pattern (specially when you need a rollback handling) but in general there are two types (choreography and orchestration). The choreography describes the interactions between multiple services, where as orchestration represents control from one party's perspective.
for simplicity you can implement the command pattern or use EAI(Enterprise Application Integration) tools like Apache camel to handle message between endpoints according to the flow.
if you have a lots of visitors it's also better to use a queue between endpoints whether with an orchestrator or without.
point of user view:
when a user click to checkout their cart. they don't expect many of steps or to do more than just wait. as keeping the connection open for response is not a good idea maybe a loader and a periodically ajax call behind it is quite enough while there are other solutions like push notification (then you can consider on fire and forget mechanism).
Your workflow for handling a request as it is defined is totally synchronous. Each step depends on the previous step, and cannot start until it finishes. However, second step does not seem to need data from the first step, so actually they could be executed in parallel.
so, what can be done is start both of them:
Check if product has enough quantity in inventory.
Checks whether the user is a fraud or not
then
wait for response and if both are ok, then creates a url to the gateway. and sends it to the user.
You can create a camel route or any other tool that implements EIP to achieve the functionality
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 am looking in to creating a notification function in Dynamics 365, and to find the best solution, I have began with searching for the possibilities (Javascript/C#/All others). Example: Sending a user a notification that a new lead is created.
Edit:It should be generic and easy to add a new notification. So maybe it should be a workflow step, or connected to an entity.
Email notification is already integrated in Dynamics 365
Microsoft Graph has a Notification possibility (Only in Beta)
https://developer.microsoft.com/en-us/graph/graph-explorer#
Create a custom entity which. And on dashboard add a Web Resource (Javascript) that looks through the entity to find if there are any Records on the current user. If so make a popup.
Use Chrome extension to notify user.
(Example: https://community.dynamics.com/crm/b/bruce365usingdynamics/archive/2017/11/02/announcing-365-notify)
Is there any other possibility you know of?
Or do you have any experience with any of these. What one should go for or not.
Your best bet is Dashboard with Posts in Timeline/social pane. This just need couple of configurations like Post rule, Timeline embedding in Dashboard & user training.
Activity feeds
Activity Timeline
If not, timely workflow or MS Flow to send a digest notification.
I would say if you wish to go code less solution then use Workflow
and place trigger as you wish. Send an Email to Either team or
particular user from this workflow. Just set regarding in Email as
Account or Contact or any entity from which you have an Trigger. By
this way You can see all these notification in your Social pane
timeline as well.
If you need some custom logic, Use plugin but in turn call a
workflow which will be onDemand workflow and this will only be used
to send Email.
There can be different Ideas as well. But we have this in place on one of our productive system and it fulfilles requirement of Notification very well.
Since you specifically want to interact with users within the CRM system, there are a number of simple approaches:
Task Queue (Passive) -
Create task records within CRM (these can also sync to Outlook if you want to get fancy). Users review a queue containing all of their tasks. You can similarly assign tasks to teams of users. I recommend this approach for CRM oriented users who have a number of different tasks.
View/Report/Dashboard (Passive) -
Create views of records requiring action. Users then review these views on a regular basis. I recommend this approach for non-time sensitive tasks, and tasks executed in bulk across many records.
Email (Active) -
Create a workflow with a Send Email step. This is easy to do but could generate a lot of emails which the users may then ignore. I only recommend this approach for rare notifications, or those requiring urgent action.
Emailed Reports (Active) -
A hybrid of the second and third approaches, there are third party solutions that will email view results to users on a scheduled basis. This would be my recommendation if you want an active approach without spamming users constantly. These are easy to install and configure and entail a small cost.
In addition to the many viable options offered above (a few of which I was unaware), if the user's daily responsibilities include working with Leads, you might want to keep it super simple - create a My New Leads view and instruct them to check it throughout the day. You could even place this view on a dashboard, making your option 3 redundant.
If the user rarely needs to concern themselves with Leads, the need for a notification strengthens. Assuming that the Lead volume will not flood their inbox, in the interest of simplicity you could start with a workflow email notification.
Our company wants to know when the case activity is 75% of the original estimated hours.
However, I think that might be a bit of a tough call.
So, can someone explain how to send an email notification from Microsoft Dynamics CRM when someone logs any kind of "case activity" against a case? I am happy to use .NET code if necessary.
Create a workflow against the 'case activity' entities, add a condition to the workflow to only send an email when the the 'case activity' is related to a case. E.g. regarding case contains data.
I would prefer a Plugin for this kind of thing because you can do a lot more within a Plugin's context.
This is what I would imagine:
Whenever an activity record is created/modified/deleted; if it is regarding a case, the plugin will execute:
Get all regarding activities for the case
Sum up the Duration
If the Duration Total is 75% of the Case Estimate then fire a
workflow
The workflow will then be configured to send an email. By combining the plugin with a workflow, you allow the email to be configurable if the wording/recipients/from needs to change in the future.
I would probably also pass in the 75% as a configuration setting to the plugin so that this is also semi-configurable (doesn't involve code - but you'd need to modify the plugin registration).
The plugin would need to cater for
New Activities being added
Existing Activities being edited (Duration and/or State changes)
At first I thought you would also need to handle Deletes, but that would drop the Duration below the 75% so you wouldn't need to send an email.