Yeah! Go away complexity! Look how much more compact the XML looks like:
Modul8 watermark update#
If the flow ends without errors, watermark will automatically update the object store with the new value. Mule will select the user object store automatically. Optionally you can specify which object store you want to use but you don’t have to.The selector collects the return values and selects the right value This expression works in tandem with the selector by being executed on each object the salesforce query returned. Finally, we entered a selector expression.In our case, we want the greatest LastModifiedDate so we’ll choose MAX There’re four available selectors: MIN, MAX, FIRST and LAST. Then we choose a selector, which is the criteria we want to use to pick the next value.This is the first big gain: we don’t have to worry about the ObjectStore’s state Then we provide the default value expression, in case the component cannot find a value for the watermark.First we provided the name of the flowVar that will hold the value.WatermarkingĪs you can see the poll element now has a watermark element that implements the same behaviour we saw in the first example but in a declarative way: The flow above is way too complex and we haven’t even done the sync logic yet! So, we came out with the concept of Watermark. At Mulesoft we believe that this use case is generic enough to deserve a simpler solution. Not so simple after all isn’t it? Let’s take a look at a sample flow that does this in Mule: Finally, you need to have logic not to update the timestamp if the sync failed.Instead, you need to select the greatest timestamp in the dataset you just got Notice that because the server time on your machine probably differs from the clock on the source system, you can’t simply use a value like “server.dateTime”. Update the persistent store with the timestamp that should be used on the next sync.Go into the source system and get all the objects that have been updated since that timestamp.If this is the first update, then you need to use a default value.Go into a persistent store and grab the timestamp for the last update.Sure, this first part sounds like the easiest of all the sync process (and in some cases it actually is), but it’s not without its complexity. Such an integration should start with getting the objects that have been modified since the last sync (or all of them in the case of the very first sync). No shame to admit it, it happens in the best families. Sooner or later, someone asks you to periodically synchronize information from one system into another.
0 kommentar(er)
