We are writing an application hosted in Excel 2002 (groan). One requirement is that, during certain operations, we submit progress messages to the user from the business layer. However, these messages can be displayed at multiple sites, one being the Excel status bar, and another being a label on a form, and possibly others in the future. In some situations, we desire to only post the message to the Excel status bar, in others, just the label on the form, and in others, both.
Currently, we have a message "hub" to which business logic can post status messages. The Excel status bar and also the form label both observe this hub, and if any messages are posted, both intercept the messages and display them- similar to mass mailings via a post office, where the sender is unconcerned with the destination.
First: Is this a generally accepted pattern?
Second: Would it be prudent for the business layer to have knowledge of the destination to which it needs to post a message? Even though the business layer is relatively decoupled from the UI through the use of the post office, what is your opinion of imbuing the business layer with, essentially, address/target/destination information?
Thanks.
If you want to stick with the conventional pattern for this type of problem then you will want to look into the Model-View-Controller (MVC) design pattern. The purpose of the pattern is to decouple business logic from the GUI(s). It allows for one model (business logic) to drive multiple different GUIs.
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
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.
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...
I am building an MVC application (using the Zend Framework).
When users first register, the applicaiton sends them an email. My question is, where should I trigger this email from? The model or the controller? My thoughts are as follows:
In some ways, the model makes sense, since sending a registration email is part of my business logic. Users must click the link in the mail to validate their email address.
But by putting it in the model, I am 'encumbering' the model. The model's registerUser action is then only useful within the context of an application that needs emails sent for every registration.
Instead, by triggering the email from within the controller, my controller would be a litter 'fatter', but my model a little more 'fine grained'.
I have written an email service which actually configures and sends the email, and I think this is a good design decision. I am really just asking where I should be calling this service from.
Your thoughts are most appreciated!
According to Zend Framework's definition of MVC, you should put send the email from the controller:
Controllers...decide which view to display based on the user's request.
Models, on the other hand, contain:
...basic functionality behind a set of abstractions.
An email may be considered a "view" in that it displays information to the user. It is the controller's job to activate this "view."
In my opinion, I would want this in the model, as I would consider this an assumed process of the create user method, rather than any specific interaction with the user making the request.
In other words, since I would always want this email sent, regardless of the source of the request, I would identify this as a natural byproduct of the create user action, similar to a record being saved in a database.
You might want to look into using something like NServiceBus to queue messages to be sent to your Email Service.
This way you can have NServiceBus subscribe to an event that occurs and omit any manual firing of the email service etc.
Ultimately you want a failsafe way of ensuring your messages get to the intended people. This kind of framework will greatly help you ensure that this happens.
Alternatively you could store the emails to be sent inside your database and have your email service check the database queue every x minutes for new emails to send and omit the need for triggering the email sending.
Again, doing it this way will ensure at the least that the emails get sent. Should the network go down or some other disruption occur during the sending of each email you can simply leave them in the queue until the network comes back up.