I have two triggers on a object.
One is managed package which I could not see or amend the content inside the trigger.
One is design by me.
I want to run my own created trigger before the managed package trigger. Could I control the sequence of the execution of the trigger.
Because it now always run the managed package trigger first. I would like to run my trigger first. I have been think for a few days. All colleague in my company could not know how to achieve this goal. Without fixing this issue, I couldn't be able to continue my work. Please help me out.
In the system there is no way to control the sequence of calls triggers, I think this limitation of unsafe programming. Do you have access to the package trigger? This is a really bad approach to have several triggers on a one object, better solution is to have a single trigger that will invoke various handlers. Then, on handlers level you can manage sequence of this handlers..
For example, this is simple trigger, which is invoked on different events and calls different methods with various logic:
trigger ContactTrigger on Contact (before insert, before update) {
/* Before Update*/
if(Trigger.isUpdate && Trigger.isBefore){
/*
here you can invoke different methods of different classes
(trigger handlers) in different sequences
*/
}
/* Before Insert*/
if(Trigger.isInsert && Trigger.isBefore){
//on other events you can use it too
}
}
}
In order to ensure that a handler can be invoked only after finishing of executing previous handler, you can use the state variables whose values will be changed at the end of handler, and you can check before calling other handlers. I hope this will help you in the future:)
Related
I'm using cqrs pattern with multiples databases (one for query and another for search). Should I put the insert inside Repository
CommunityRepository{
Add(Community community){
Database1.Insert(community);
Database2.Insert(community);
}
}
and then:
CommunityCommands{
Handler(AddCommunityCommand community){
communityRepository.Add(community);
}
or should i put this in Commands, like this:
CommunityCommands{
Handler(AddCommunityCommand community){
db1.Insert(community);
db2.Insert(community);
}
or maybe something like this, using the main repository + database2
CommunityCommands{
Handler(AddCommunityCommand community){
communityRepository.Add(community);
db2.Insert(community);
}
I would do neither of those options as you'd be basically coupling the Command and Query immplementations.
Instead, publish events from the Command side, like OrderPlacedEvent and subscribe to them from the Query side. This not only allows you to separate the implementations of the Command and Query sides, but it will also allow you to implement other side effects of the events without coupling the code from the multiple features (eg. "when an order is placed, send a confirmation email").
You can implement the pub/sub synchronously (in process) or asynchronously (with a messaging system). If you use messaging, note that you'll have to deal with eventual consistency (the read data is slightly behind the write data, but eventually it catches up).
refreshing the Query Models should be handled in an offline operation. You should do something like this:
process your Command logic (whatever it is)
right before your Command handler returns, send an Event to a message bus
then in a background service you can listen to those Events and update the Query side.
Bonus tip: you can use the Outbox pattern to get more reliability. The idea is to store the Event messages in a table on your Write DB in the same transaction as your previous write operation, instead of sending them directly. A background service would check for "pending" messages and dispatch them. The rest is unchanged.
I have an always one application, listening to a Kafka stream, and processing events. Events are part of a session. And I need to do calculations based off of a sessions data. I am running into a problem trying to correctly run my calculations due to the length of my sessions. 90% of my sessions are done after 5 minutes. 99% are done after 1 hour. Sessions may last more than a day, due to this being a real-time system, there is no determined end. Session are unique, and show never collide.
I am looking for a way where I can process a window multiple times, either with an initial wait period and processing any later events after that, or a pure process per event type structure. I will need to keep all previous events around(ListState), as well as previously processed values(ValueState).
I previously thought allowedLateness would allow me to do this, but it seems the lateness is only considered for when the event should have been processed, it does not extend an actual window. GlobalWindows may also work, but I am unsure if there is a way to process a window multiple times. I believe I can used an evictor with GlobalWindows to purge the Windows after a period of inactivity(although admittedly, I did not research this yet, because I was unsure of how to trigger a GlobalWindow multiple times.
Any suggestions on how to achieve what I am looking to do would be greatly appreciated, I would also be happy to clarify any points needed.
If SessionWindows won't do the job, then you can use GlobalWindows with a custom Trigger and Evictor. The Trigger interface has onElement and timer-based callbacks that can fire whenever and as often as you like. If you go down this route, then yes, you'll also need to implement an Evictor to dispose of elements when they are no longer needed.
The documentation and the source code are helpful when trying to understand how this all fits together.
According to the docs, Marionette.Application provides three "action" methods:
Application.execute - execute some action but register it first with MyApp.command('action', function () {});
Application.request - is like Application.execute but can return something
Application.trigger - is the same as Application.execute.
What's the difference between Application.trigger and Application.execute?
When A calls execute, it orders B to do something. There's a somewhat direct link: one orders, the other executes (i.e. something must happen).
Triggers simply trigger an event to indicate something happened in the application. Other sections of the code might be listening for that event and react to it, but it also possible that no one is listening (so nothing will happen). Basically, by using triggers you can easily implement a publish/subscribe pattern in your application.
For completeness, there's also a triggerMethod call in Marionnette: it triggers the "some:event" signal, but also executes the onSomeEvent function if applicable. For example, myView.triggerMethod("some:event") will trigger the "some:event" within the myView scope and call myView.onSomeEvent.
Is it possible, or more precisely how is it possible to use RX.Net to listen to a number and different variety of (WinForms) controls' .TextChanged/.RowsChanged/.SelectionChanged events and whenever one condition is fullfilled (ControlA.Text isn't empty, ControlB.RowsCount > 0 etc) enable that one DoSomething button.
I am asking because currently we have a lengthy if/then statement in each of these events' handlers and maintaining them if the condition changes is, due to duplicate code, quite error prone and that's why, if possible, I think it would be nice to take the stream of events and put the condition in one place.
Has anyone done that?
You can use Observable.FromEventPattern in combination with Join patterns, with Observable.When, Observable.And and Observable.Then, to create observables which will fire depending on various conditions, like combinations of events. For example, consider my answer here: Reactive Extensions for .NET (Rx): Take action once all events are completed
You should be able to use .FromEventPattern() to create observables for each of those events and then use CombineLatest() to do your logic on the current overall state and determine whether your button should be enabled, in one place.
I have couple of objects(1 custom object called appointment and event object) which i am trying to syncronize. So i have 1 trigger each on each object which searches and updates the records. The issue is, these triggers will keep running recursively as everytime an appointmet is updated the event is also updated and the triggers keep firing and ofcourse salesforce does not accept it.
Any idea how to overcome this?
Thanks
Easiest way is to have an apex class containing a static boolean variable initialised to false. Then in each of your triggers you would check the state of this variable:
trigger MyTrigger on MyObject (after update)
{
if(CStaticTracker.bHasTriggerFired == false)
{
CStaticTracker.bHasTriggerFired = true;
// do your work and update the other object here
// shouldn't need this but let's play safe!
CStaticTracker.bHasTriggerFired = false;
}
}
The upshot being, of course, that when one of the triggers runs it'll set this variable to true, and prevent the recursive trigger from executing whatever logic is contained within the if statement. Of course this can still cause some cascading, but it will stop as soon as you don't call another update in one of the triggers.
Good luck!