Dennis Frostlander
My feedback
-
5 votesDennis Frostlander
shared this idea
·
-
51 votes
Thank you for your feedback! This work is on our backlog. However, it is unlikely to happen in the coming year. We will update here if this changes.
Dennis Frostlander
shared this idea
·
-
5 votes
Mr. Frostlander,
Thank you for sharing your feedback.
In regards to programmatic ISV scenarios we had designed the job collections with intention of mapping either an ISV user or application representation to a job collection so that the ISV entity can have multiple jobs and they can be managed together. In your scenario you have not created that mapping. If we were to increase the job collection limit for a particular plan what would a reasonable limit be?
In regards to authentication the Scheduler service has a new REST interface behind the Azure Resource Manager (ARM) which allows you to use OAuth tokens. Would that work for you?Regards,
Kevin LamAn error occurred while saving the comment An error occurred while saving the comment Dennis Frostlander
commented
Hi Kevin,
Thanks for a prompt reply.
1. Thank you for the tip about Resource Manager. I think that will work. The main goal was to avoid deployment of publish settings/management certificates, which will be achieved by using bearer tokens.
It still would be nice to have managed API wrapping raw http requests though, but it's not high priority.2. Regarding the job limit, it's quite hard to say. Generally, I don't feel safe when there is a limit. There is always this subconscious feeling "what if somebody publishes an article about my service and 10 000 users will subscribe for a 10 day trial"?
So I would personally feel much safer if I were to pay for a number of jobs that I have and didn't have to think if they would fit inside a job collection.Thanks,
Dennis.Dennis Frostlander
shared this idea
·
-
16 votes
Mr. Frostlander,
Thank you for your feedback, We can look at possibly adding a flag to a job that will automatically delete a successfully completed job.Regards,
KevinDennis Frostlander
shared this idea
·
-
22 votes
Thanks for your feedback.
-Kevin
Dennis Frostlander
supported this idea
·
Hi again,
Actually, regarding suggestion #1 (authentication and API), oauth is not as convenient as I thought. Interactive logon is a no-go for such scenarios, and for other grant types you need to mix and match different approaches for different scenarios - e.g. for scheduling from web app you need reply urls, for scheduling from console apps (or integration tests), you need some other grant type, etc.
I actually find it easier just to deploy management certificates and use service management API rather than setting up all the oauth things.
So I would stick to my original suggestion - make access to scheduler using a connection string to make scheduling of jobs as easy as inserting an entity into a table storage.
Thanks,
Dennis.