User-defined Robot

[LaRetta]

Hi everyone,

I am setting up a client box with an FM file called eMailer which will check 'periodically' for eMails (which will appear in a portal in eMailer) when they are ready to be sent. eMailer has a field (type timestamp) called Now which is Get ( CurrentTimeStamp ). This timestamp is used in the relationship to eMailLog and determines when something will pop into the eMailer as day/time to send.

Robot will be perpetually looping and sending emails. However, I see no need to check for emails all night. I would like a User be able to specify:

Monday start at 6:00 AM and end at 8 PM. Fire every 5 minutes.

Tuesday ...

Saturday start at 8:00 AM and end at 5 PM and fire every 30 minutes.

Maybe I shouldn't worry about it. I'm just afraid that, if I fire the process every 5 minutes, 24 hours a day, 7 days a week, it will use electricity uselessly or wear out the computer or something. At this point, I have no idea how often we will want to fire it but most of the emails will need to go out at least every 10 minutes. I also don't know if they will REALLY want ability to modify it depending upon day of week but I'd prefer to plan for it than not.

My thought was to create records at 'firing points' (a record for each increment for each day). But I recall Comment's calendar solution and this feels just as clunky as creating days ahead when unnecessary. So, knowing the goal, how might you 'all approach coding 'browse-mode capability' for User but eliminate convolution? Use one record with repeaters?

Since it will always be running, I can use variables/script etc for tracking, counting, checking the time and so forth ... but capturing the default settings (letting a User specify them) is a bit sticky for me. Oh, and the reason I don't want to use Scheduler is because, if communication with host is lost then scheduler puts up a stupid dialog and won't let FM continue. By error trapping for that within FM, it won't be held up ... at least ... that's my story and I'm stickin' to it.

LaRetta

Edited April 11, 2008 by Guest

[comment]

Do you really need a different schedule for each day of the week? I'd think one for a work day and another for weekends/holidays should be enough?

In any case, you will need a table for holidays (and perhaps other exceptions). I believe the rest could be in repeating fields, i.e. if no related record in holidays, use StartHour[DayOfWeek(today)], etc.

[LaRetta]

You are correct, I couldn't imagine needing different schedules for some weekdays; I was considering holidays in there (and ability to change for upcoming holidays) on the fly.

Alright, I believe I can run with that concept, using Get ( CalculationRepetitionNumber ) and a few example files here. I will see what I can come up with. Thanks for pointing me in the right direction! :smile2:

[comment]

Ahm... I don't see where Get ( CalculationRepetitionNumber ) would come into play here.

[LaRetta]

To extend out the timeslots by specified duration without creating records.

Using your laminated calc, no? I thought you gave me enough to run with it; now I wonder. :crazy2:

Edited April 11, 2008 by Guest

[comment]

I must be missing something in your description, because I don't follow (I don't even know which calc is the laminated one). Why do you need timeslots? I'd think that once we know today's date, we also know the start time, the end time and the interval. So when current time is a multiple of interval away from start time (and not yet after end time), that's the time to run.

[LaRetta]

So when current time is a multiple of interval away from start time (and not yet after end time), that's the time to run.

Originally, I planned to pause/resume according to the User-specified interval. Since the current time is part of the relationship (along with a static 1 - email record is flagged when ready), it needs to update (by going to layout where it is displayed). Then I would check if there are related email records to send. There are also housekeeping tasks which will be performed (file moving, renaming) and I was unsure how long everything will take.

By using interval in pause/resume, time might not be multiple of interval. That's when I turned to records or repeaters idea. I thought it would be better to pause for 5 minutes than to continually loop every second until 5 minutes was up. It would look something like:

Main menu is where unstored Get ( CurrentTime ) resides (which is parent key).

Loop

Pause/resume [ gInterval ]

If [ not IsEmpty ( eMailLog::eMailID ) ]

...gtrr and loop send

...do other housework

Go To Layout [ Orginal ] ... which will update unstored calc key

End If

End Loop

It is the issue of pulling in start/stop and day of week (discounting holidays etc) where I turned to thought of using records in parent and looping through parent instead of using the unstored Get ( CurrentTimestamp ) calculation and handling it all by script with multiple Ifs. The loop would check for day and Go To Next Record. Or using Repeaters which would filter the relationship. Once an email is sent it would disappear from relationship.

Any additional thoughts appreciated; otherwise I will attempt to run with your suggestion of handling it all by start/stop, interval and holiday relationship and letting script check for multiple of interval. Although I think it means continually checking the time every second, it seems the way to go overall. Thank you, Michael!

[comment]

I think it means continually checking the time every second

I don't think that is necessary. When the script has finished its chores, it should consult the preferences regarding the next call, and put itself to sleep until then*.

I've made a little sketch file that shows the calculations you could use in the script. It's not yet perfect, since it does not check for TOMORROW being a holiday, but it could be a useful starting point, I think.

---

(*) You should also consider what happens if there's a restart. etc. - so maybe something like:

If [ Get (ScriptParameter) ]

Pause [ Duration = Get (ScriptParameter) ]

End If

# Do stuff

Perform Script [ this script ; Parameter = time until next trigger ]

PeriodicTrigger.fp7.zip

[bcooney]

LaRetta,

Wasn't sure if you wanted to consider using 360Works SMTP plugin that works on FMS9! You could then have a server script send the emails.

Barbara

[LaRetta]

Hi Barbara!

Thank you but there are many reasons that we want it native if possible (if it can be elegant enough). But I will certainly keep this in mind. :wink2: