Best answer

Use data in current call of trigger from the last trigger call

  • 22 July 2021
  • 2 replies
  • 32 views

Hello, glad to meet  with great community.

 

I have WebAPI for trigger which has date range, like StartDate and EndDate. We have a lot of data and we decided to limit them for dates range. Now I am setting up new intergation based on this API. I want to set these two inputs parameters automatically like:

StartDate = 01-01-1900 for first call of trigger OR EndDate from previous call of the trigger.

EndDate = current date.

 

As result I want to see next picture, for example:

1 call of trigger - StartDate = 01.01.1900, EndDate = 01.05.2021

2 call of trigger - StartDate = 01.05.2021, EndDate = 01.06.2021

3 call of trigger - StartDate = 01.06.2021, EndDate = 01.07.2021 and ect.

 

How can I get access to input values from previous step and also I must be sure that previous call was successful.

 

Thanks and best regards.

icon

Best answer by Zane 26 July 2021, 20:31

For a polling trigger, I don’t think you’re going to want to implement it this way. The way a Zap with a polling trigger works, is by saying “run this workflow, for every new item of data found in a result from my endpoint, from the moment the user turns the Zap on and after”. In other words, we’re not going back to the beginning of time and loading all data in your database. For a polling trigger, your endpoint should provide the items in reverse chronological order. When the Zap first turns on, we’ll take everything we see and populate a de-duplication database. We won’t process those items. On a subsequent poll, we’ll grab the most recent data your endpoint provides, compare it against the dedup database, and if we find previously unseen items we’ll use those to process through the Zap, and then add those to the dedupe database, so we know not to handle them again when we see them in subsequent requests. In other words, just provide the most recent objects from the last 15-30 minutes or so and we’ll do the rest. 

That said, in terms of your use case, the “let’s go back to the beginning of time and let the user choose to load everything” feature, stay tuned - we’re working on a mechanism to add this functionality in addition to today’s “from-this-point-on” event streaming way of automating workflows. 

View original

2 replies

Userlevel 7
Badge +9

For a polling trigger, I don’t think you’re going to want to implement it this way. The way a Zap with a polling trigger works, is by saying “run this workflow, for every new item of data found in a result from my endpoint, from the moment the user turns the Zap on and after”. In other words, we’re not going back to the beginning of time and loading all data in your database. For a polling trigger, your endpoint should provide the items in reverse chronological order. When the Zap first turns on, we’ll take everything we see and populate a de-duplication database. We won’t process those items. On a subsequent poll, we’ll grab the most recent data your endpoint provides, compare it against the dedup database, and if we find previously unseen items we’ll use those to process through the Zap, and then add those to the dedupe database, so we know not to handle them again when we see them in subsequent requests. In other words, just provide the most recent objects from the last 15-30 minutes or so and we’ll do the rest. 

That said, in terms of your use case, the “let’s go back to the beginning of time and let the user choose to load everything” feature, stay tuned - we’re working on a mechanism to add this functionality in addition to today’s “from-this-point-on” event streaming way of automating workflows. 

Ok, thanks. Main idea was to do not load the database with heavy queries. When specifying the period, we receive a request much easier in terms of the load on our base.

Reply