I have a workflow similar to the one from http://msdn.microsoft.com/en-us/magazine/hh288072.aspx.
Most of the time it works great. Sometimes however, it crashes and then says "An error has occurred in workflow CreateSiteFlow". The site then has been created successfully.
I found some references to the same problem, but all say to look at the log files. How does this work for SharePoint Online, or has someone guidelines for what could be wrong?
I found some references online about time-outs regarding to workflows. But I cannot find any specifics about this, and also I'm unable to see long time (including seconds, or even more precise) in the reports of the workflow..
Regards,
Matthijs ter Woord
Related
We have been going through the cycle of submission, refinement, submission. Normally we get a very detailed report with the findings. However, our most recent response from the team was a generic:
We’re sorry, but we encountered an error while processing your app and
need your help to continue. Please submit your app for approval again,
and we will continue the validation process.
How can we get feedback on what this means, what was the root cause, and what we can do to ensure this doesn't happen. Our team wasn't notified of this issue, and only noticed it by checking the status several times a day.
When issues like this arise, is there a way to triage the issue faster or at least set it up so that we receive notifications proactively rather than passively?
Microsoft is in the process of modernizing a lot of the infrastructure that processes add-in submissions (to fix the issues such as the one that affected your add-in submission) - when we complete this work in forthcoming months, you should not encounter these issues any more. It was not caused by something you did wrong during submission time.
Until our updated services are released, I'd encourage you to check the email you used when registering with AppSource/the Office Store. Checking the Seller Dashboard site will also show you the status information.
If you have further questions, please provide the name of your add-in submission and we can contact you directly.
Thanks,
David Mowatt
Office Store Program Management
I see there's been quite a few topics covering this error on Sharepoint, but not quite one where it happened to someone who's been using SSRS.
So I have this report which users need to access, with most of them it opens fine and they can use it.
But recently, two new users can't open the report.
They get the following error:
I tried to google and see whats wrong, but I cant find anything.
I've created page workflow to update data in external list:
When I execute this workflow, I get an error. I don't know what causes the error:
I've read about permissions to the Sharepoint system account. I feel like I've tried everything.
Do you have any ideas what can cause this error ? Is there any way of debugging such workflows in Sharepoint designer ? I've tried reading Sharepoint logs, but nothing interesting there.
TIA for any clues.
I've managed to do that, I needed to configure Secure Store Service application:
link 1
link 2
Not quite sure what I've done to screw up SPD2010 (was working), but it displayed
Sharepoint Designer cannot display the item
What you can try:
Click refresh ... blah
Most likely causes
The file has been deleted from the site
The site is encountering problems
I can't see anything related in event viewer. I think is web service related as I think the queries are made via a WS?
In my case it wasn’t a solution. So, I made a backup of the site collection before to try anything. After a lot of time and different problems I figured out that some lists were causing the missreading. I tried one more time to get the lists in SharePoint Designer 2010 just to cause some entries in the log. After that I opened the log file and looked for something like: “Failed to determine the setup path of the list schema for feature {GUID}, list template XXX.”. With the GUID I looked for a match here. http://sharepoint-geek.com/2010/10/08/sharepoint-2007-moss-features/
With the feature name I used this blog: http://aurramu.blogspot.com/2011/03/failed-determine-setup-path-of-list.html.
With the feature re-installed I went to SPD and it worked like a charm.
I hope it helps someone else.
It appears this was caused by a "phantom" list definition. I experienced a number of other problems (some in SP some in SPD), all generating variations of this error;
<nativehr>0x8107058a</nativehr><nativestack></nativestack>
The problem list definition was deployed and undeployed from VS2010, so I have no idea why it was still around! The Sharepoint UI wont allow you to remove it (errors as above), so the trick is to use the stsadm powershell command with forcedeletelist as detailed here
http://technet.microsoft.com/en-us/library/cc262609(office.12).aspx
Hope this helps someone else !
We have a long standing issue in our bug tracking system about the dreaded "ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads." message in SharePoint's trace log.
As we develop Workflow software for the SharePoint market, we look into this issue from time to time to make sure it is not caused by our products. I have personally come to the conclusion that this is a problem in SharePoint, but perhaps someone else can prove me wrong.
Here is what I know:
According to the hundreds of search results returned by Google on this topic, this issue appears to be mainly related to SharePoint Workflows, both SharePoint Designer and Visual Studio based workflows.
Assuming ULS logging is set to Monitorable, the easiest way to reproduce this problem is to create a new SharePoint Designer Workflow, attach it to a document library, set it to auto start on add/update, don't add any actions, save the workflow and upload a file to the document library.
The error is only visible in the SharePoint trace log, it does not appear to impact the execution of the workflow at hand.
I have verified that the problem occurs on 32 bit as well as 64 bit systems, Win2K3 and 2K8, WSS and MOSS with SharePoint versions up to the December 2009 Cumulative Update (6524).
The problem does not occur when a workflow is started manually.
There are dozens of related posts on MSDN Forums, hundreds on Google, one on StackOverflow and none on SharePoint Overflow. There appears to be no answer.
Does anyone have any idea about what is going on, what is causing this and if we should worry or file this under 'Red Herrings'.
Update: Microsoft has confirmed this is a known issue that can be safely ignored. It will not be fixed in SP2007, but is no longer a problem in SP2010.
File it under Red Herrings. You say "The error is only visible in the SharePoint trace log, it does not appear to impact the execution of the workflow at hand." There are so many errors logged in the ULS Log that are beyond our control and do not immediately impact our environment. If you want to improve the product you could attempt a support call that may be non-incremented as a bug. However, what if it's not a bug, but just a verbose ULS Log message?
In fact, this verbosity isn't limited to just the ULS Logs. Have you seen the Microsoft Office SharePoint Server 2007 Management Pack for System Center Operations Manager 2007? It filters out the noise events from the Event Logs on your farm so you can concentrate on the events that flag an actual problem.
This is a really good question and I'm starving to see good responses to this. I've seen this error in my workflows in very different contexts.
For instance, In my case it happens in a home-baked custom activity when I catch the "task created" event and try to "breakroleinheritance" of the SPListItem (the new task).
My custom activity gets workflow context through a property wfActProps which is of type SPWorkflowActivationProperties. Then I typically use wfActProps.Web to access the web object.
The first thought I had that maybe it's a bad tone to pass SPWorkflowActivationProperties between different activities, however I have not found any different way yet.
I'm setting "community wiki" to my answer since this is not an actual answer, rather an example of a situation where this error can be seen.
When I look at the stacktrace (I'm assuming the person who posted that message is referring to the same error), it looks like an OOTB event receiver (Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver) which is responsible for autostarting workflows is disposing an SPSite that may not have been created by the event receiver code.
Unfortunately the AutoStartWorkflow() method is obfuscated so I can't really see in Reflector which SPSite is being disposed. You could experiment writing your own EventReceiver that disposes any existing SPSite it can get it's hands on and see if that causes the same error to be logged.