If I'm reading the documentation correctly, one way to customize the behavior
of spree is to listen to fired events. One event is "order_finalized".
From where can I get a list of events that my spree application "fires/ supports"?
At the moment the events fired by default in Solidus are:
order_finalized
reimbursement_reimbursed
reimbursement_errored
Events are in an experimental phase. That's the reason why there is a small number of events currently but they are used in production by several stores and Solidus welcomes Pull Requests that add more events when needed by developers.
Related
I've come across a strange issue with the Slack API/Bolt library, whereby listeners which work when triggered by genuine messages (i.e. sent via the Slack GUI) trigger these events with no issues, but messages which should trigger the listener that are sent through code work only very sporadically (maybe once eveery 10-15 times, usually a bit more after you've re-installed your app to the workspace).
The below code is an example listener:
#bolt_app.message("test")
def test_funct(message, say):
say("found")
The following is an example snippet to produce a message which meets the criteria:
client.chat_postMessage(
channel="#test-channel",
text="test"
)
I've tried using an alias for bot when sending, but no notable difference. Permissions all check out according to the documentation. It's also worth noting that the client configuration is the same for both (we're using the same app and the same tokens etc).
I do not see any tracked events on MIKROS Analytics. I have followed all the steps from the Get Started guide.
My app is approved and I already have an "appGameId" and my "apiKey". I am using the Production "apiKey" for now.
Some other information. I have auto initialization enabled under Mikros Settings in the Inspector. I also tested without auto initialization and initialized the MIKROS SDK at app start like this,
MikrosManager.Instance.InitializeMikrosSDK();
I tried to log a custom event like this,
// log events
AnalyticsController.LogEvent("mikros_analytics_test", "parameter", "app_open", (Hashtable customEventWholeData) =>
{
// handle success
},
onFailure =>
{
// handle failure
});
Any idea why I am unable to see any events on the dashboard? Or what step(s) I am missing?
Don't forget to define the namespaces at the top of your scripts as well.
using MikrosApiClient;
using MikrosApiClient.MikrosAnalytics;
It takes some time after the app is not being used before all events are fully logged. However, you can manually log them by calling:
AnalyticsController.FlushEvents();
Also make sure you have the following at the top of your script:
using MikrosApiClient;
using MikrosApiClient.MikrosAnalytics;
Ref: https://developer.tatumgames.com/documentation/log-events
Similar to other analytic services such as Firebase Analytics or Unity Analytics, MIKROS Analytics queues your events and will send them out in batches. There are certain criteria required in order for the batched events to be sent off.
While both Firebase and Unity can take up to a maximum of 24 hours before events can be viewed on their dashboards, MIKROS has a max time of about 10 hours. However, in most cases MIKROS tracked events will be posted more immediately. The 10 hour timeframe is when the entire batch of events is forced cleared from the queue.
If you want more control of how immediate events are sent off you could force event uploads using flush(). Call the method after you have tracked your events.
MikrosManager.Instance.AnalyticsController.FlushEvents();
It is not really necessary, but it's an option available to you.
What core Moodle events will allow me to see when a student navigates between areas of a course? I need to build an event trigger plugin, to call an external REST endpoint, every time a student navigates between screens, begins or ends a course module, etc. The Event API docs has a long list of events, however I cannot find anything which details when the event will actually fire. Also, the only activity I can find, which seems to remotely relate to what I'm looking for is course_module_viewed and, unfortunately, that event name repeats in many areas:
core\event\course_module_viewed
mod_lti\event\course_module_viewed
mod_page\event\course_module_viewed
mod_resource\event\course_module_viewed
mod_url\event\course_module_viewed
I think you're right that you want "course_module_viewed" events - but that event is (should be, because it ties into default activity completion options) implemented by each activity/resource type, because it could mean different things. So if the activity is a "page", then viewing it will trigger mod_page\event\course_module_viewed and if the activity is a SCORM package, mod_scorm\event\course_module_viewed. All of these should extend the abstract core\event\course_module_viewed class.
There is not a default event for moving between pages within an activity - at that level of granularity you are dependent on whether the implementers of that plugin decided to log events for this or not, or indeed whether the activity even has pages.
Other events you may be interested in are core\event\course_viewed and core\event\course_completed which only exist in core, and the various other events that each individual activity you're likely to encounter in your course content fires off. Eg. for a SCORM activity, you might be interested in the "mod_scorm\event\status_submitted" event
When subscribing to Calendar Channel, https://developers.google.com/google-apps/calendar/v3/push, should I expect to get a push notification for each new event created?
In testing, if I create 21 events (each at 2 second intervals), I get about 7 notifications.
It's hard to tell from the docs if I should be getting a notification for each event created, or if I should use the notification to do a sync?
What are you guys doing for your apps?
Google Calendar watches only make sense when you're also using the sync token feature. They are basically instructions to do another sync, which will bring in 1 or more event changes. The reason you got less than 21 messages is because Google rate limits the messages (in your case to what looks like every ~3 seconds... my experience is closer to 10s).
The callout about not being 100% reliable is actually a bit of a different concern than the "only 7" callbacks issue. Until yesterday, my experience was that watches were 99.9% reliable in terms of delivering a notification within a few seconds of a change. But for the 0.1%, you'll want to have some sort of fallback force sync... could be once an hour, could be upon login, etc.
I've noticed similar. Scroll down to the very bottom of that page you linked:
Notifications are not 100% reliable. Expect a small percentage of messages to get dropped under normal working conditions. Make sure to handle these missing messages gracefully, so that the application still syncs even if no push messages are received.
If you've called watch on the calendar to register/create a notification channel, I'm assuming they're doing some throttling/bucketing to push out notifications at a coarse-grained level. Testing this out myself but I believe the original intention of asking for incremental changes via setting timeMin equal to a previously requested syncTime still holds true:
https://developers.googleblog.com/2013/07/google-calendar-api-push-notifications.html
I am trying to wrap my head around Saga's using Jonathan Olivers EventStore and CommonDomain. I understand how Aggregates are working with the CommonDomain/EventStore but I am stuck on grasping Saga usage. I have read both of Jonathan's Saga's with Event Sourcing Part I & II but sill lost in actual implementation
1) More of observation, when persisting the saga the EventStore is utilizing the Headers to persist the Saga and Commands that need to be sent out and it looks like the Payload is storing the Event that triggered the Saga to "wake up". Wondering reasons for this. Would we never want to store individual commands vs having them all in the header?
1) It seems like the Event that triggered the Saga gets replayed multiple times since the "Transition" method in SagaBase always re-adds the event to uncommitted collection. (Unlike ARs that have an internal Apply method vs public Domain method). Maybe I am not using the Transition method properly
2) Typically the bus that you use with the EventStore will publish Events (I implemented IPublishMessages). If I need my Saga to publish a command there does not seem to be a Send option. Do I need to parse the Headers to grab the commands myself?
I am thinking I am using the CommonDomain / EventStore incorrectly as working with Aggregates was easy but Saga's seem "incomplete" to me. I am assuming its because I am not doing it correctly. Still very new to CQRS. Does anyone have a working example of Saga's using J Olivers Common Domain / Event Store? I think that would clear things up considerably.
[EDIT]
I think I figured it out but would like some input. Saga's really should not be publishing events. They send out commands. Thus on the publish side of things for the EventStore (IPublishMessages) I should first be checking the type of message (AggregateType vs SagaType) For AggregateTypes I can publish Events but for SagaTypes only publish the commands (found in Header). This eliminates the same event (say OrderSubmittedEvent) that triggers the creation of the Saga to not publish it again when persisting the saga.
The commands are put in the headers to be sent on the bus. The EventStore is concerned with the storage of events so the events that caused saga transitions are persisted. Later, when the saga is loaded from the event stream, the events will be passed to the saga's transition method to bring it to the current state.
The transition method serves a dual purpose in the saga implementation. Transition is called to handle incoming messages and to load the saga from peristence. In SagaEventStoreRepository.BuildSaga ClearUncomittedEvents and ClearUndispatchedMessages are called on the saga after the current state is built up thus avoiding duplicate event and command processing.
I haven't personally done this but I would use a separate EventStore instance for my sagas. This would allow for the usage of a separate IPublishMessages implementation to take the commands from the event headers and send them.