When you query EWS or Outlook API for appointments restricted by some period for recurring ones you get fake instances. Exchange keeps only the main instance with recurrence pattern and exceptions list, and if one have to use MAPI one should "unpack" this solo appointment to get occurences by hand. That's not the problem ) The real pain I still cannot cure is how to get main appointments which reside outside of given period but their occurences are inside, I want to evade getting all recurring appointments (or even at some reasonable distance from given period for example a year to the left), "unpacking" and checking for ocurrences which are between our dates.
The current action sequence:
IMAPITable.Restrict on dates
.SetColumns
.QueryRows
Do MAPI interfaces have some methods or parameters which allow to achive my goal?
Here http://www.pcreview.co.uk/forums/redemption-recurring-activities-t2964080.html I've found detailed answer: pidLidClipStart and pidLidClipEnd instead of PR_START/END_DATE filtering.
Related
I am implementing an example of spring-boot and axon. I have two events
(deposit and withdraw account balance). I want to know is there any way to get the state of the Account Aggregate by a given date ?
I want to get not just the final state, but to replay events in a range of dates.
I think I can help with this.
In the context of Axon Framework, you can start a replay of events by telling a given TrackingEventProcessor to 'reset' it's Tokens. By the way, the current description on this in the Reference Guide can be found here.
These TrackingTokens are the objects which know how far a given TrackingEventProcessor is in terms of handling events from the Event Stream. Thus resetting/adjusting these TrackingTokens is what will issue a Replay of events.
Knowing all these, the second step is to look at the methods the TrackingEventProcessor provides to 'reset tokens', which is threefold:
TrackingEventProcessor#resetTokens()
TrackingEventProcessor#resetTokens(Function<StreamableMessageSource, TrackingToken>)
TrackingEventProcessor#resetTokens(TrackingToken)
Option one will reset your tokens to the beginning of the event stream, which will thus replay everything.
Option two and three however give you the opportunity to provide a TrackingToken.
Thus, you could provide a TrackingToken starting from several points on the Event Stream. So, how do you go about to creating such a TrackingToken at a specific point in time? To that end, you should take a look at the StreamableMessageSource interface, which has the following operations:
StreamableMessageSource#createTailToken()
StreamableMessageSource#createHeadToken()
StreamableMessageSource#createTokenAt(Instant)
StreamableMessageSource#createTokenSince(Duration)
Option 1 is what's used to create a token at the start of the stream, whilst 2 will create a token at the head of the stream.
Option 3 and 4 will however allow you to create a token at a specific point in time, thus allowing you to replay all the events since the defined instance up to now.
There is one caveat in this scenario however. You're asking to replay an Aggregate. From Axon's perspective by default the Aggregate is the Command Model in a CQRS set up, thus dealing with Commands going in to your system. In the majority of the applications, you want Commands (e.g. the requests to change something) to occur on the current state of the application. As such, the Repository provided to retrieve an Aggregate does not allow specifying a point in time.
The above described solution in regards to replaying is thus solely tied to Query Model creation, as the TrackingEventProcessor is part of the Event Handling side in your application most often used to create views. This idea also ties in with your questions, that you want to know the "state of the Account Aggregate" at a given point in time. That's not a command, but a query, as you have 'a request for data' instead of 'the request to change state'.
Hope this helps you out #Safe!
I am new to Event Sourcing and I have encountered an example which I am not quite sure the pros and cons of different approaches.
Let's say this is a bank example, I have three entities Account, Deposit and Transfer.
My idea is, when a use deposits, command bank.deposit will create two events:
deposit.created and account.deposited. Can I or should I include the deposit.created event uuid in account.deposited as a reference?
Taking to the next step, if later the bank has a transfer feature, should I made a separate event account.transfer_received or I should created a more general event account.credited to be used by both deposit and transfer?
Thanks in advance.
A good article to review is Nobody Needs Reliable Messaging. One key observation is that you often need identifiers at the domain level.
For instance, when I look at my bank account, and see that the account history includes a specific deposit, there is an identifier for the deposit that is reported in the view.
If you imagine it from an event sourced perspective, before the deposit the balance was X, and the history did not include deposit 12345; after processing the deposit, the balance was X+Y and deposit 12345 was in the account history.
(This means, among other things, that if a second copy of deposit 12345 were to appear, the domain model would know to ignore it even if the identifier for the event were different).
Now, there are reasons that you might want to keep various message ids around. See Hohpe's work on Enterprise Integration Patterns; in particular Correlation Identifier.
should I made a separate event
Usually. "Make the implicit, explicit". The fact that two events happen to have similar representations is not a reason to blur them when the ubiquitous language distinguishes the two.
It's somewhat analogous, in motivation, to providing a task based ui or eschewing the user of generic repositories.
I am studying CalDAV protocol.
I have some question for time conflict or overlap for CalDAV.
Let me explain by instance for some scenario.
I made an event PM1 ~ PM6 in calendar. And then I try to made another event PM2~7 in same calendar. It is time conflict or overlap.
How does CalDav server resolve this conflict? Does server make error when second event make?
I did search out RFC 6638. But I could not find solution.
Please help my question.
Thanks for reading.
It is up to the CalDAV client to decide how to behave when overlap is involved.
If the client decides to write an event that overlaps another the server will write the overlapping event.
When scheduling is involved (userA wants to invite userB to a meeting but would like to avoid picking a time slot that is already busy in userB's calendar) the CalDAV client can query the FREEBUSY status for a user (see RFC 4791). There's also availability which allows a CalDAV client to retrieve a user's availability (think business hours).
The functionality Kim is asking for a very common one for business calendaring systems (not have the same person booked twice etc).
I think in the CalDAV world there are two parts to this:
a) First the client is supposed to perform a freebusy query to check
whether a user is available. And then show a conflict warning or
whatever seems appropriate.
This is how many systems, including btw Exchange work. Siri also does this kind of conflict detection (“hey, you already have an event at the time, shall I still create the conflicting one, master?”)
b) But in a reasonable system you actually need to guarantee that
the information isn’t outdated at PUT time. I.e. that no second
client has scheduled the same attendee/resource.
I think in CalDAV you can accomplish that by testing the sync-token or the CTag using an If header on the PUT. I.e. let the PUT only succeed if the whole underlying collection didn’t change. And if it did (the PUT will fail with a conflict), redo the freebusy, then try again.
I don’t think that there is a reliable way to do this in CalDAV cross collections (calendars), that is, if the availability of a resource changed because it got booked in a different calendar, the targeted sync collection won’t usually change its sync tag and the PUT would run through.
The bad thing about CalDAV (w/ scheduling) is that PUTs are not idempotent anymore. Otherwise you could do the PUT, recheck whether it still has no conflicts, and if so drop it after the fact.
I have about 38,000 subscribers in an Interest Group. Using segments I identified around 9,000 subscribers that I'd like to remove from that Interest Group. On the MailChimp website it is incredibly cumbersome to remove them. You can only select a maximum of 100 at a time(only 100 show up on a page before needing to click to the next one). And once you click Actions > Remove from Group they remain in the auto-updating segment making it very difficult to select only the ones you haven't done yet.
Can MailChimp's API let me do this faster?
Yes! MailChimp allows you to send Batch Update queries which you can use to unsubscribe users from the mailing list.
You can use MailChimp's batch endpoints to make a series of PUT requests updating those subscribers fields. So each individual operation would be made against a lists members instance (documented here).
I'm writing an application that queries a user's Outlook calendar to see if they are available to be contacted "right now" (i.e., they do not have a current appointment that is marked as Away or Out Of Office).
I'm using the GetUserAvailabilityRequest xml message and it's working well, but I'm a bit confused as to what I should use for the AttendeeType.
AttendeeType is a field that allows me to specify the kind of meeting attendee I'm looking for -- whether it's the meeting organizer, a required attendee, an optional attendee, a room resource, etc.
But for this application I don't care about the attendee type; I only care if the person has a current appointment that marks them as unavailable. If Bob is out of his office attending a meeting, I don't care if he put the meeting together or if he was invited by Carol; I only care that Bob is out of his office.
Is there a value I can use for AttendeeType that will catch all attendee types? Most of the examples I've seen use the value "Required", but they don't explain why.
I've found that both OptionalAttendee and RequiredAttendee are valid, so the choice to use RequiredAttendee is entirely stylistic/arbitrary.
I believe that this is sort of a hypothetical query, like "If this person were to come to an event at this time as an optional attendee (or as a required attendee), would they have conflicts?" So it doesn't matter if they are required or optional.
As an aside, resources are things like projectors and rooms, so I'm not sure what would happen if you tried to check a person as a resource, but I imagine it wouldn't work out.