Getting context can be a real pain since technically
- there IS NO CONTEXT when you are inside a scheduled process.
- and no context means not portalid - to get portal settings from.
- The easy way to get CONTEXT is to actually NOT user the scheduler process for your send processing.
1. Create your send code in a standard web module - this also makes it MUCH easier for testing since you can do all your testing without worrying about the scheduler handling.
Once the system is working completely:
- create a simple SCHEDULER STUB module that does only one thing
- which "is" make a http request to the page on your website ...
The only problem you have here is working out how to get the scheduler stub to call the right page.
For my scheduler modules
- we created a small SQL table that holds a list of web pages to call
- we also do some schedule management in the table as well since, we occasionally see double bounce type issues with the built in scheduler - that is - the scheduler firing more than once for the same time segment.
Since your scheduler stub is actually calling a page inside your website
- the full context of your site is available to the send processing.
The other advantage from a development point of view
- is that once you have coded and debugged your scheduler stub
- you can do all your remaining testing on the WEB PAGE itself - which makes for much easier debugging.
Westa
Westa