I have created a simple workflow start-->createoredit-->automaticactivity-->End. automatic activity doesnt do anything, i have default code in the script area of automati activity FinishActivity "Automatic Activity Finished" alone in the script area.
When i trigger the workflow, automatic activity is not started and performed, it is assigned to "NTAUTHORITY SYSTEM" with the state "Assigned" (In the Global Work List)
Whenever i restart the "Tridion Workflow Agent" service or whenever some other automatic activity assigned via workflow, automatic activity start performed.
I dont see any error message also in the event log.
Could anyone help me on this? I am using SDL Tridion 2011 SP1.
The first activity must always be a manual activity. If you need to have the first activity automated then you need to rely on the event system for this.
EDIT: I see you wrote the question to add the first activity to be manual.
When an automatic activity gets stuck in Assigned state, it usually means there is a script error. There could also be something with the connectors between activities in your Visio design. Check that everything us properly connected. Try deleting the link between automaticactivity to End and recreating it again.
Check that the "Tridion Content Manager Workflow Agent" windows service is running. This fixed it for us.
Related
I want to find information about a terminated instance in BizTalk 2010 - where can I look for that information? Specifically, I'm looking for information about an instance for one application.
You might start up the BizTalk Administration Console and go to the BizTalk Group node.
Then, on the page thats pops up, select 'Tracked Service Instances'.
Given the fact that you are tracking the specific instance you want to find, you might be able to find this by extending the query with "State" equals "Terminated".
Depending if you tracked it or not AND how long ago it was AND how long your tracking is kept in the DTA database (see the SQL jop parameters for that), you will find what you are looking for.
Hope this helps.
Specifics notwithstanding, all available information about any instance can be viewed in BizTalk Administrator through the context (right click) options.
The only other place you may find relevant information is in the Event Viewer if there was a previous error.
There is no special database-only log or other source of information.
How can I add and remove a TrackingParticipant to a WorkflowServiceHost that is currently executing workflow instances, alternatively change the TrackingProfile of an already existing TrackingParticipant of that host?
The reason I need to do this is that the WorkflowServiceHost is executing workflows on certain events in our system, so it may run several workflows simultaneously. Now I need to enable tracing of these activities during runtime for diagnostic purposes upon a user request, an then disable them again when the user no longer needs them. I can't restart the host because the workflows may be long running. However adding an extension to a WorkflowServiceHost that has already been associated with a workflow throws an exception. And the TrackingProfile of a TrackingParticipant seems to only be changeable at construction(?).
One way would be to simply have my TrackingParticipant have a boolean flag that indicated whether it was enabled or not, and then have it always track everything, but simply doing nothing with them if it was disabled. However, when I tried this the perfomance impact was not acceptable. Having a tracking participant that did absolutely nothing in its Track method made an example workflow consisting of a simple while-loop take 10 times longer to execute.
So is there any way to accomplish what I want here? And if not, why not?
We would like to implement some functionality so that when for some reason an error occurs during publishing or resolving, and we skip over it using a try/catch block, but would still like to notify the user that something was skipped.
The SDL Tridion 2011 Publishing Queue can filter by status. One of these statuses is “Warning”. Is it possible to trigger a publish transaction to have a “Warning” status using the API in either template code or a custom resolver?
If all you need is a warning during the publishing (such that the Publish Transaction has status warning), then you will need to set PublishInstruction.MaximumNumberOfRenderFailures to something greater than 0. As long as the number of Render errors is lower than the max you specified, the status of the Publish will be Warning.
If an error occurs outside rendering, then the instruction will show as Failed.
On the other hand, if you want to show a message in the GUI (in the MessageCenter) with the 'Warning' that something went wrong, then you will need a more complex architecture. Frank worked on this a while back. The idea (IIRC) is to have a GUI piece, e.g. an iframe polling a service that returns statuses for that user's Publish actions. An event system would produce these statuses by monitoring the PublishInstruction, and it would write them into some kind of storage (file, db, memory) that the service would then poll.
I'm afraid this isn't possible, but the answers above might help you find an alternative solution to this.
I have a workflow service that links a Workflow Foundation 4 process with an application database which stores records that show what step our users must complete next. In the event of a non-resumable error in the workflow, it will make it so that the workflow is unable to be resumed, but the database entries that are in the application still exist, so there is a "disconnect" between workflow state and our application state.
What I would like to do is create another instance of the failed workflow, but get it into sync with the application database entries. That would entail going to an arbitrary entry point in the workflow based on the application database entries that exist.
Is it possible to do this? Are there any pitfalls to doing so? Is there a better way to manage the workflow to application dependency?
The workflow would look something like this:
Start the workflow. This creates an application db record that tracks the progress of the process and a db record that shows the user what needs to be done next.
The user "works" the step, which does a call into the workflow service (using receive/sendreply), updating the db record with the outcome of the work, and moving to the next step in the workflow.
Step 2 repeats with all the various steps creating db records to be worked, then updating those records with the results of being worked and creating new db records to be worked, until the process completes.
The question I'm trying to answer is if the user gets to a certain step in the process and the workflow engine fails so that the workflow instance is not resumable, how might I use the application db entries to "restart" the process to re-enter the process, skipping to the point of failure (assuming we had resolved the issue that caused the failure in the first place). This would eliminate the user having to "redo" work that had already been done, and stay in the process.
What I thought was that if there was a way of looking at the application database records that have been created to determine where the process had died, if I could "skip" previously finished steps and move to the point in the workflow that failed based on those db records, I could "resume" the process (from the user's point of view) without causing rework.
I'm just starting out with Workflow and I've been watching some videos on channel9 at MSDN and I came across one that may help you out.
It talks about using Bookmarks and some Task based-API by Ron Jacobs.
Check it out at: Workflow TV - WF4 Workflow Episodes - a Task Based API
It sounds like what you want to implement is Compensation- that is, custom rollback functionality built into a transaction. Here's the start of the Transaction and Compensation activity documentation:
http://msdn.microsoft.com/en-us/library/ee358756.aspx
You can use the Compensate activity to do database cleanup after a failed transaction.
I need to invoke a long running task from an ASP.NET page, and allow the user to view the tasks progress as it executes.
In my current case I want to import data from a series of data files into a database, but this involves a fair amount of processing. I would like the user to see how far through the files the task is, and any problems encountered along the way.
Due to limited processing resources I would like to queue the requests for this service.
I have recently looked at Windows Workflow and wondered if it might offer a solution?
I am thinking of a solution that might look like:
ASP.NET AJAX page -> WCF Service -> MSMQ -> Workflow Service *or* Windows Service
Does anyone have any ideas, experience or have done this sort of thing before?
I've got a book that covers explicitly how to integrate WF (WorkFlow) and WCF. It's too much to post here, obviously. I think your question deserves a longer answer than can readily be answered fully on this forum, but Microsoft offers some guidance.
And a Google search for "WCF and WF" turns up plenty of results.
I did have an app under development where we used a similar process using MSMQ. The idea was to deliver emergency messages to all of our stores in case of product recalls, or known issues that affect a large number of stores. It was developed and testing OK.
We ended up not using MSMQ because of a business requirement - we needed to know if a message was not received immediately so that we could call the store, rather than just letting the store get it when their PC was able to pick up the message from the queue. However, it did work very well.
The article I linked to above is a good place to start.
Our current design, the one that we went live with, does exactly what you asked about a Windows service.
We have a web page to enter messages and pick distribution lists. - these are saved in a database
we have a separate Windows service (We call it the AlertSender) that polls the database and checks for new messages.
The store level PCs have a Windows service that hosts a WCF client that listens for messages (the AlertListener)
When the AlertSender finds messages that need to go out, it sends them to the AlertListener, which is responsible for displaying the message to the stores and playing an alert sound.
As the messages are sent, the AlertSender updates the status of the message in the database.
As stores receive the message, a co-worker enters their employee # and clicks a button to acknowledge that they've received the message. (Critical business requirement for us because if all stores don't get the message we may need to physically call them to have them remove tainted product from shelves, etc.)
Finally, our administrative piece has a report (ASP.NET) tied to an AlertId that shows all of the pending messages, and their status.
You could have the back-end import process write status records to the database as it completes sections of the task, and the web-app could simply poll the database at arbitrary intervals, and update a progress-bar or otherwise tick off tasks as they're completed, whatever is appropriate in the UI.