Multi-tenants created after publish still run a "when published" timer?

Multi-tenants created after publish still run a "when published" timer?

  
I have the following scenario:

1. Publish eSpace with a "when published" timer.

2. Create a new tenant.

3. That tenant has the timer run for it, even though it was published before the tenant was created.

Is this normal behavior?

J.Ja
Hello Justin,

what's the setting of the "Is Multi-tenant" property of that timer?

It is not possible to say, per configuration, that  a timer runs for one tenant and not for another. If you set a timer as Multi Tenant all queries will have their data isolated per tenant, if not, they'll "have" access to data from all tenants.

From the help: " Timers: Allow narrowing the scope of execution of timers by tenant. Single-Tenant timers will run on the default tenant (which has the same name of the User Provider application)."

Cheers
Pedro Cardoso

Pedro -

It is a multi-tenant timer.

The problem is that a tenant made *after* the timer has run, will then have the timer run for it. That is counter-intuitive. The timer was run "when published", I would not expect it to also run "on tenant creation".

J.Ja
Ah!

I got your question now, sorry :)

Well, I can see your point on that, but I can also see the point on the guys that developed the feature. Since it's common to use "when published" timers to bootstrap data for an app, if it wouldn't run when a new tenant is created, you could start a new tenant without some data and make an app unusable... definitely a detail to add on the help page about Timers and MultiTenancy

Cheers
Pedro
Pedro -

Yeah, the problem is, the tenant creation process *also* bootstraps data, so this behavior causes the migration to run twice, which is potentially a problem depending on what it does.

J.Ja
I see... so there's another process bootstraping data? How was that achieved?
Pedro -

We never directly call "Create", "Update", "Delete", or "CreateOrUpdate" from our applications, we have an action for "Upsert" (Insert + Update) and "Remove" which handle all of the business logic around our data. The Upsert always has a branch for a new record, which handles all defaults. This way, the person working on UI never needs to know what the defaults should be, unless they need them for the display. In our case, the UpsertTenant has logic doing things like setting defaults, bootstrapping default settings elsewhere, etc.

J.Ja
Ok Justin, I get it.

I'm guessing that you don't need any help with this other than clearing that infact the timers run when a tenant is created, is that right?

Pedro
Pedro -

Yup, I just wanted to confirm that this was expected behavior, and make sure that the answer was in a public place so others could find it. :)

J.Ja
Hi,
Just for reference, if you set a timer with:
  • Schedule: when published;
  • Is Multi-tenant: yes
Once you publish you application the timer runs once for each tenant. This means that if you have five tenants, the timer runs five times.
Also, whenever you create a new tenant, the timer runs.

To make things simpler, imagine that you just started your application, created a multi-tenant timer, and published. This is what happens:
  • When you publish the application, a default tenant is created. So the timer runs once for that tenant.
  • You then go to Service Center, and create three more tenants: one for companyA, other for CompanyB, and yet another for CompanyC.
  • Each time you created a tenant, the timer runs. So a timer will run for CompanyA, then for CompanyB, and finally for CompanyC.
  • You then fix some bug in your application, and publish it again. Since you have four tenants (the default one, and one for each of the three companies) the timer runs four times.
If you don't want this behavior, simply change the timer to Multi-tenant: No. This way, the timer only runs when you publish your application.
Joao -

Thanks for confirming that this is the wy it works! I think the best thing for me to do is to set a Site Property listing when the timer last ran, and check at the beginning of the timer to see if the Tenant's creation date is more recent than the timer's last run date, and if so, exit early.

J.Ja
Experts,
Is it the right understanding that :
1.Whenever a tenant is created irrespective of whether the tenant has created through service center or by any custom tenant creation UI (thorugh TenantCreate action) if there is timer set as 
  • Is Multi-tenant: yes then the timer will also be run and the corresponding data will be bootstraped to the application.
Please clarify the doubt.

Regards
Jdq
Depends. Is that timer set to "When Published" or something else? If it is set to "When Published" then yes, it will be run.

J.Ja
Hi JJ,
Thanks for the reply
The timer is having value with:
  • Schedule: when published;
  • Is Multi-tenant: yes
Its quite obvious that the timer will run when the osp get published or when the eSpace get published but the doubt is around when again it will run .
Is it every time a tenant is created through  custom tenant creation UI (thorugh TenantCreate action)  or I need to invoke the timer progamatically.
I want the timer to be run every time I create a tenant on the application (tenant created thorugh TenantCreate action)

jdq

Yes, they will run when the tenant is created.

This has been confirmed by OutSystems, please read the posts above.

J.Ja