I'm trying to implement automatic backfills in Argo workflows, and one of the last pieces of the puzzle I'm missing is how to access the lastScheduledTime field from my workflow template.
I see that it's part of the template, and I see it getting updated each time a workflow is scheduled, but I can't find a way to access it from my template to calculate how many executions I might have missed since the last time the scheduler was online.
Is this possible? Or maybe, is this the best way to implement this functionality on Argo?
Related
I'm trying to find whether the Episerver Scheduled job (Episerver CMS 11) is triggered manually or automatically.
While on finding in Episerver documents I do see the 'ScheduledJobTrigger' and 'ScheduledJobLogItem' are related to this. But still, I am unable to find out how to call the service for implementation and get the expected value. Can anyone help me on this?
In code, the ScheduledJob will not have a user associated with it's context when fired automatically (either via API or scheduled firing), whereas a manual start will have user context associated to it.
If you are looking to identify if this was triggered manually, checking that user context may be what you are looking for.
So there is List Release Deployments API. It allows to get all the deployments started after the given timestamp. However, how to get those completed after it?
Rationale
Suppose I want to write a scheduled job that fetches information about completed deployments and pushes it to an Azure Application Insights bucket (for example for DORA metrics). I do not understand how it can be done easily without the ability to filter by the completion date. A relatively hard way would be to fetch by the started date, notice all the deployments inProgress or notDeployed and record them in a dedicated database. Then on the next polling cycle fetch new deployments and all those still recorded in the aforementioned database. This is much more complicated than it could have been with the ability to filter by the completion date.
Am I missing anything here? Maybe there is a simpler way (possibly using another API) that I just do not see?
EDIT 1
By the way, the hard way is even harder than I thought, since apparently there is no way to fetch release deployments by their Id.
EDIT 2
The plot thickens. If a stage has post deployment approvals, then the stage is reported as inProgress, even though de facto it has already been deployed. So an API that just filters by completion date would omit such deployments. It has to be with an option to include such deployments.
I'm using a third-party solution, that effectively offers a limited MWF interface when it comes to Workflow development.
The challenge I have is that I am trying to utilise the workflow scheduling interface, that would allow me to have workflows re-occurring at prescribed times/dates etc. No problem here. However, due to the underlying data, I need to store a key to this data in the initiating workflow, which is then accessible to all subsequent "child" workflows. I've tried setting an Argument field, In/Out & In, in the workflow, but this is not preserved in subsequent iterations. Any solutions? Thanks
So in one part of our customised Salesforce system, the following happens:
a trigger changes the value of a picklist on a custom object
a Workflow rule detects that change and fires off an email.
Since about the 4th of December though, it seems to have stopped working.
edit: The Debug Logs show that the trigger is firing and changing the value of the picklist, but no Worflow Rules are evaluated.
The workflow rule is pretty simple, so I don't really understand whats preventing it. The details of the rule are:
Operates on a custom object.
Evaluation Criteria: When a record is created, or when a record is edited and did not previously meet the rule criteria
Rule Criteria: ISPICKVAL(Status__c, 'Not Started')
Active: Yes
Immediate Workflow Actions: an email alert
Edit: The Rule does fire if I manually update the object to set the appropriate status. But it isn't firing when a trigger changes the status.
Edit: Did something change on Salesforce around December 4th 2009? That seems to be when this stopped working ...
Any ideas?
If you had said "the trigger does not fire the workflow, even though a manual change via the UI does", I would have responded something like...
Absolutely. That's how it is designed.
Salesforce do not allow anything
automated to invoke anything automated
(ie you cannot start a WF from a trigger or another WF).
Given that you say this stopped working earlier in the month, I am frankly astonished! We wanted to achieve something like this, would have been about 10 months ago, and Salesforce told us it could not be done; they like to keep tight control over processes that could potentially run away and consume large CPU (because of the multi-tenanted nature of the offering), hence the stringent governor limits...
This may have changed recently, of course, we built work-rounds to get round the restriction...
To answer my own question ... I eventually found out what this was.
The Salesforce Spring '09 Workflow Rule and Roll-Up Summary Field Evaluations update was rolled out to all orgs at the start of Dec '09, and changed certain Workflow behaviours.
The update improves the accuracy of
your data and prevents the
reevaluation of workflow rules in the
event of a recursion.
Our particular problem was that we needed Workflow to be evaluated twice on a single object after the initial action - we had a series of changes to a status field that needed to kick off different things. After the Spring '09 update, Workflow is only evaulated once for an action on an object.
So, it did work, but then the platform changed, and it didn't work anymore. Time to write some code.
I’m about to write a workflow in CRM that calls itself every day. This is a recursive workflow.
It will run on half a million entities each day and deactive the record if it was not been upodated in the past 3 days.
I’m worried about performance has anyone else done this.
I haven't personally implemented anything like this, but that's 500,000 records that are floating around in the DB that the async service has to keep track of, which is going to tax your hardware. In addition, CRM keeps track of recursive workflow instances. I don't have the exact specs in front of me, but if a workflow calls itself a set number of times within a certain timeframe, CRM will kill the workflow.
Could you just write a console app that asks the Crm Service for records that haven't been updated in three days, and then deactivate them? Run it as a scheduled task once a day, and then your CRM system doesn't have the burden of keeping track of all those running workflow instances.
EDIT: Ah, I see now you might have been thinking of one workflow that runs on all the records as opposed to workflows running on each record. benjynito's advice makes sense if you go this route, although I still think a scheduled task would be more appropriate than using workflow.
You'll want to make sure your workflow is running in non-peak hours. Assuming you have an on-premise installation you should be able to get away with that. If you're using a hosted instance, you might be worried about one organization running the workflow while another organization is using the system. Use the timeout and maybe a custom workflow activity, if necessary, to force the start time to a certain period.
I'm assuming you'll be as efficient as possible in figuring out which records to deactivate. (i.e. Query Expression would only bring back the records you'll be deactivating).
The built-in infinite loop-protection offered by CRM shouldn't kill your workflow instances. It stops after a call depth of 8, but it resets to 1 if no calls are made for an hour. So the fact that you're doing this once a day should make you OK on the recursive workflow front.