Scheduled jobs and HttpContext

Vote:
 

It always used to be that you could work out whether a job was running via scheduled execution or run via the Admin mode interface by checking within the job whether there was an HttpContext. If there was, then the job was run via Admin mode. If not it was scheduled.

Has this behaviour changed?

I'm on CMS 10.10.1 and HttpContext is always null, so I can't see a way to identify the context in which the job is run. I'm guessing may this changed with some of the improvement work around making jobs stoppable / supporting dependency injection etc. Are jobs run in their own new thread now perhaps?

Does anybody know if this is a deliberate thing?  

Can anybody think of a way to work out if the job was manually started?

#187138
Edited, Sep 23, 2019 17:41
Vote:
 

If memory serves it was a deliberate change to always start it up in their own thread.

I don't recall what version it was, but before the change when a job was started manually and run in the current HttpContext the job would also be aborted if the HttpRequest timed out.

No idea if you can find out if a job was manually started now.

#187184
Jan 15, 2018 17:03
Vote:
 

I believe this changed in cms 10.3 so it's a while ago. It doesnt matter anymore if you start it manually or automatically, the job is always run in the same context.

The trigger is set in SchedulerOptions upon execution but I haven't found a way to reach it from within the job. However, the trigger is set in tblScheuledItemLog. It's an int value that corresponds to the enum ScheduledJobTrigger.

#187185
Jan 15, 2018 17:35
Vote:
 

Thanks both. Good to know. That has some impact for anything that relies on an HttpContext. Nothing that can't be worked out though!

My exact requirment was to know the context so I could block automatic scheduling of the job (meaning the specific job can only be run by clicking 'start' in Admin mode). You can still do this - though its a bit of a hack. You check the job settings via the ScheduledJobRepository. If it is marked as IsEnabled (meaning it is set in Admin mode to run automatically), then I return from the job. I only allow it to execute if it isn't saved in the database to run on a schedule. 

var job = _scheduledJobRepository.List().First(j => j.TypeName == GetType().FullName);
if (job.IsEnabled)
return "Execution of this job is disabled. Please turn off scheduled execution to allow this job to be executed manually";



#187203
Jan 15, 2018 23:56
Vote:
 

Is there any consideration that forces it to be a job?

If a schedule isn't wanted I would prefer to add it as a Tool under CMS->Admin.

#187222
Jan 16, 2018 12:36
Vote:
 

Good point Erik.

In my exact case, there is a bit more context that forces it to be a job. It should run automatically in the Production environment only, I only want to disable scheduled execution on downstream test environments.

#187224
Jan 16, 2018 12:48
Vote:
 

That makes sense. As long as it is only for a test environment hacks are allowed. wink

#187226
Jan 16, 2018 12:58
Vote:
 

Haven't tested this in CMS 11, but I've solved the same issue like this 

if (PrincipalInfo.CurrentPrincipal.Identity.IsAuthenticated)
{
   //is in admin mode
}

since a scheduled execution is run in an anonymous user context.

Got this tip from Philip 

#187285
Jan 17, 2018 21:34
Vote:
 

I realise this is an old thread. I was looking for the answer and discovered a solution.

I found the following works:

var path = new EPiServer.Web.Hosting.AspNetHostingEnvironment().MapPath(localPath);

#207498
Sep 23, 2019 4:27