In our project, at individual workflows, we have enabled concurrent workflow execution, that enables execution of the same workflow at the same time, and this can cause some issues.
There are 100's of such workflows. Is there a way to disable the concurrent workflow execution at the same time from admin console, so that we avoid having to disable it at each workflow?
This would save time and effort.
Mass-editing workflows is not supported. And there is no global configuration to enable / disable concurrent execution.
One way might be: exporting => editing XML files => importing. Or using external scheduler to take care of it.
Related
I was reading about Spring Batch and I read the below:
Spring Batch is not a scheduling framework. There are many good
enterprise schedulers (such as Quartz, Tivoli, Control-M, etc.)
available in both the commercial and open source spaces. It is
intended to work in conjunction with a scheduler, not replace a
scheduler.
Source: https://docs.spring.io/spring-batch/docs/current/reference/html/spring-batch-intro.html#springBatchBackground
So what is the difference between Spring Batch and Tivoli?
Spring Batch is mainly designed to provide a runtime for java batch workload.
IBM Workload Scheduler (Tivoli) / HCL Workload Automation, like other schedulers, doesn't run the workload directly, but is used to triggers any kind of workload (jobs), including Spring Batch, on on-prem or hybrid and multi cloud environments, including Kubernetes.
It can trigger jobs based on calendar, time, considering free/working day, complex runcycles (e.g. 3 working days before the end of each month).
In addition it can trigger workload based on dependencies on other jobs, so that they can start as soon as the previous job (running on any other system) has completed successfully, or run jobs only if predecessor has completed with a specific RC or result. Or you can use logic resources and limits to control how many jobs using the same machine or resource can run at the same time.
It can be also used to trigger workload based on events, e.g. when a new file is uploaded.
In recent releases IBM Workload Scheduler / HCL Workload Automation also added built-in capabilities to transfer files.
IBM Workload Scheduler / HCL Workload Automation is also key to have a centralized monitoring and recovery of failures, to centralize security granting access to different teams only on their jobs, to have a centralized governance (e.g. auditing any change and recovery on jobs).
It's also able to forecast the job durations and when every job will run, and generate alerts if they are running too long or if based on predecessors they are expected to miss their deadline.
Tibco Spotfire:
Automation Services vs Scheduled updates
Both tools are allowing caching the report in order to improve its performance but I wonder if you guys know the difference?
Scheduled Updates caches the analysis (data , visuals ect) for a quick load time. Automation Services is a services that allows you to perform automated steps on the analysis while opening (IE: Exporting PDFs , Sending Emails , Saving Analysis as Embedded data.
Caching the analysis and Saving the data as embedded are two different things. Caching will ensure the entire dashboard is readily available in cache resulting in fast load times on webplayer. Saving as embedded saves the underlying data to the dxp as SFBD (spotfire binary data) files for quick load time of the data when accessed in the webplayer.
Automation services also has the ability to set any amount of refresh and at any intervals while Scheduled updates is a bit more strict, this is due to automation services using a task scheduler and the server to open and perform actions while schedule updates only opens and caches data.
I have a few instances where I use both Automation services to refresh data , send email notifications ect and then Schedule Updates also runs on the same analysis (very large data sets). This allows me to refresh at 8am , 9am , 11am , 1pm , 5pm in automation services and scheduled updates ensure end users webplayer loads immediately.
In addition to what #Tyger Guzman said....Scheduled updates are used exclusively for the web player to make projects open faster by caching the data. Scheduled updates don't help desktop users with load time at all. That's where Automation Services comes into play. Yes, you can perform tasks (as described above, which Scheduled Updates don't do), but Automation Services can also be used to cache and make desktop load time faster when the project is connected to an information link and when the information link is setup to hold cache. Basically you use AS to open a project (i.e. ping an IL), before users open the file. Because the IL is setup to cache, all subsequent requests to the IL open faster. AS is the trigger. Neither AS or SU work with prompts.
I'm wondering how long a Dynamics CRM workflow will stay in a Status Reason of "Waiting" before it times out/gets cancelled automatically?
I have a workflow for "Renewal" Opportunities with the following step: "Wait until Today's date >= 3 months before Renewal Date." Then, the record is updated. I'm worried that if the workflow has a status of "Waiting" for too long, it will cancel automatically. Will this be an issue? If yes, what is a better way to handle "Renewal Opportunities", so the Opportunity Name gets updated with the word "Renewal" 3 months before the date in the "Renewal Date" field?
Thanks!
It will wait indefinitely. But... as someone who has written products that rely on waiting workflows, I can say that there can be issues. Perhaps most prominent is the risk of the workflow getting cancelled before its trigger date - not "automatically" but by a user or user-defined process.
One client has routines that cancel waiting workflows on a regular basis. That broke everything all the time until we moved their scheduling out of workflows to an online scheduler.
In general it's fine to rely on waiting workflows that are scheduled months out, but it's also prudent to have a mechanism to confirm that they're operating and recover when they're not.
Aron did a good job of tackling the first part of your question.
If yes, what is a better way to handle "Renewal Opportunities", so the Opportunity Name gets updated with the word "Renewal" 3 months before the date in the "Renewal Date" field?
1) Create a procedure:
Often a manual procedure is more cost effective and reliable than developing automation.
- Create an Opportunities Pending Renewal view which shows all opportunities where the Renewal date is within X days of today.
- Create a Renew Opportunity workflow
- Put in place a process where by a user regularly (once a month/ once a week?) opens this view and runs the Renew Opportunity workflow.
This is a good option if the renewal does not need to occur on an exact date.
2) Have an external application launch the workflows:
You could write a lightweight scheduled application to carry out this operation. If you take this route, I recommend keeping as much of the configuration in CRM as possible by having the application execute over the results of a CRM view and kick off workflows to carry out the renewal action. That way when your business decides to change their rules (e.g. different renewal period) you just update the view criteria or workflow.
This is a good option if you have in-house dev power and if there are many such workflows that you can leverage your scheduled application to handle.
3) Have a plugin launch the workflows:
This is my personal preference. Same as Option 2 except rather than using a scheduled console application you let CRM host and schedule the job. Create a custom scheduled task entity, and set up a workflow which waits for some period (e.g. 24 hours) then creates a scheduled task record. Add plugin logic which fires on-create of scheduled task records, which carries out the same actions from option 2.
This is better than #2 for several reasons:
- Does not require external hosting, no integration concerns
- The job can be triggered manually simply by creating a scheduled task record
- You can add result logging to the scheduled task record
Other thoughts:
I won't pass judgement on whether the above options are "better" than waiting workflows, they all have different strengths and weaknesses. The Async service is much more reliable that it was historically, but I personally still try to avoid using workflow which wait for extended periods of time, primarily for system complexity and performance reasons. If you need automation and don't have in-house developers, then your best option probably is to set up waiting workflows.
Since some months, Wercker add a feature to execute 2 concurrent builds.
The problem is that during the build, it report tests results in Sonar and Sonar can handle multiple reporting at the same time. That why, I would like to disable this feature. I found nothing in the documentation to do that.
Do you have a solution to disable concurrent build feature?
I'm an employee from wercker. We've had the concurrent builds from the beginning, currently the default is 2. It is not possible for a user to change the concurrency.
However Wercker can manually change the concurrency for a user account to 1 by contacting the Wercker support.
I have a workflow that runs when an entity is created and it creates two other entities and puts them on a queue. It then waits until each entity's status reason is set to done. After which is continues.
Basically two teams will work an order and then it will continue processing after both teams are done.
Most of the time it works. However sometimes it waits forever. I'll re-active and re-resolve the other tasks, but it just never wakes up.
What can I do? The workflows aren't really powerful enough for me to have it poll with a timeout (there are no loops). I'd like to avoid on-change plugins for these other entities to get workflow behavior all scattered about.
Edit:
Restarting the CRM services (not sure which did it, I restarted them all) allowed the workflow to resume. However, I'd still like to know how to make this more reliable.
I had the same problem (and a lot more) with workflows in CRM 2011 and decided not to use them (except for very special purposes).
The main reason is because of their very limited error handling. Another reason is that it is inconvenient to put them under source control. Another reasons are: Worflows cannot run offline and user impersonation is also not supported. For a comparison look here: http://goo.gl/9ht1QJ
Use plugins instead of workflows, then you have full control.
But keep in mind that plugins (unlike workflows) are not designed for long running tasks.
So they have a default max execution time of 120 sec and are not stateful/persisted. But in most cases (and i think also in your case) that is not a problem.
Just change your eventing a little bit:
Implement and register a plugin step for: entity is created and it creates two other entities and puts them on a queue
Implement and register another step: entity's status reason is set to done, query for other entity and check status, if done continue processing
If you really do not want use plugins for you business logic you can consider implementing a plugin which restarts/resumes faulted workflows.
But thats not a very nice solution.