I'm working with Beta 2 of Visual Studio 2010 to get some advanced understanding of WF4. I've created a workflow that has a Pick Activity that is contained in an If Activity. In the Pick Activity I have two Triggers, one that contains a Delay set with a TimeSpan of 10 seconds, the other Trigger has a Bookmark for a manager to approve. I'm trying to use the Delay to set a "state" variable to "Expired" if the manager doesn't approve in the allotted time. This is very similar to what Matt Milner did in his post at: http://msdn.microsoft.com/en-us/library/ee342461.aspx, except he uses a DoWhile Activity, whereas I need to use the If Activity I've described here. I'm also using persistence and hosting the workflow from an ASP.Net application. I'm wondering if the problem I'm seeing is caused by the internet browser not keeping the workflow running in memory, and there is no way for the workflow to come be re-started when the delay completes.
If you are using the WorkflowServiceHost, or a XAMLX, to host the workflow you will need to configure the WorkflowManagementService to reload and restart the workflow. If you are using the WorkflowApplication you are responsible for reloading the workflow after it has been persisted.
But as Chris said: a bit more info on what is actually going wrong might be helpful here.
Related
I wonder if the community out there can help with this.
We are using Microsoft Dynamics 365 v8.2.2.112, on-premises (not cloud).
The problem is this: millions – yes, literally millions – of Contacts are being created for no apparent reason.
Our users access CRM via an intranet page, but also using the CRM Outlook Plugin.
Since upgrading to v8.2 in January, something in CRM is creating millions of CRM Contacts.
The same Contact is being repeatedly re-created hundreds and thousands of times for the same user. And this happens for multiple Contacts and for multiple users. The end result is that millions of Contacts are being generated. The contact gets created every 5 minutes (approx).
You can easily see the Contacts being created. If you run an “Advanced Search” on Contact order by “created_on” descending order, you can see the same new Contact being generated every five minutes or so, and whose details exactly match the one created 5 minutes ago.
We’ve got about 20 users who seem to be particularly prolific Contact creators. Possibly because of the nature of their role, they add lots (ie dozens) of Contacts to Outlook (but they definitely don’t add hundreds of thousands of the same person!)
I'm absolutely baffled as to why this should happen.
The prevailing view at my company is that CRM Outlook synchronisation is to blame. We use the Outlook plugin widely. We use version 8.2.3.8 of the Outlook CRM plugin. When users sync their Outlook Contacts, maybe it doesn't recognise that the Contact is already in CRM, so regenerates it? We think it's a bug of that nature.
We can’t turn off Outlook synchronisation, because users require it in order to do their jobs. They need to be able to sync Activities, Emails, Contacts and so on.
We've checked all our custom code (C# plugins) to ensure that no Contacts are being create anywhere. We've especially checked the "on create" of Contacts to ensure it’s not creating an additional Contact. No code generates Contacts.
I understand that I am able to turn off users' Outlook Synchronisation filters. But I don’t want to do so as they do need to be able to sync with Outlook. It’s one of the reasons we use Dynamics CRM.
Does anybody know what’s causing this? Has anybody come across this before? What’s the solution to stop this happening? I'm after a root-cause if possible!
Just wanted to keep this post up to date, for the benefit of any other poor souls who encounter this ghastly problem.
We were in touch with Microsoft who have been very helpful (although weren’t able to provide a “silver bullet” solution). The case is ongoing.
The first suggestion was that the problem was down to a customisation, integration or homemade plugin that had got itself into an endless loop, creating CRM Contacts ad infinitum. After searching absolutely every line of code and custom logic, I was able to confirm that the problem is not down to any of our customisations.
What we then did was to examine the Contacts being created on mass. We identified one Contact that was being generated over and over again. We checked its owner, let’s call this owner “John Smith”, and found that John Smith was the one creating this contact over and over. So we checked John Smith’s “Appointments, Contacts, and Tasks” syncing. We did this by “Settings -> Email Configuration -> Mailboxes”, then searched for John Smith’s mailbox. From John Smith’s mailbox, under the “Synchronization Method”, we set “Appointments, Contacts, and Tasks” from “Server-Side Synchronization” to “None”.
After doing this, the mass Contact generation immediately stopped. I’m not suggestion this is the solution to the problem (because we need to use syncing), but I am suggesting that this proves that the problem is down to a CRM bug in synchronisation (and not caused one of our customisations).
So if you’re getting this issue, and you want to rule out your customisations, I would follow these steps (above) to prove that it’s not your code that is responsible. If you turn off syncing for a user, and it stops generating millions of the same contacts owned by that user, I’d say you’ve got the same bug as me.
I think this bug is described in 2 possible places:
“Duplicate contacts are created if the rebuild of ID mapping fails after a test and enable.”: https://support.microsoft.com/en-in/help/4046463/service-update-9-for-microsoft-dynamics-365-8-2-1
OR
“Contact synchronization that uses server-side synchronization causes infinite updates.”: https://support.microsoft.com/en-us/help/3203310/update-0-1-for-microsoft-dynamics-crm-2016-service-pack-1
The suggestion is that we’re getting this problem because we’ve not installed cumulative updates before installing a major version. I can’t agree that we were meant to. We installed the latest version as directed on-line. Obviously we can’t now install the updates which allegedly fix this bug, because we’re on a later version. We went from CRM 8.1.1.1005 to 8.2.2.0112 by skipping 2 cumulative versions (i.e. 8.2.0.0749 and 8.2.1.0176). It is alleged that these skipped versions had a bug fix for this issue in it (see link above), and by not installing them, this issue happened. I can’t really agree that it says anywhere to do this (install cumulative updates before installing a major version). Anyway, that’s the suggested cause of the issue.
Anyway, we’re still busy with the Microsoft guys. I’ll get back to you when there’s a definite course of action we can take. So it’s still work in progress.
We’re planning on deleting the millions of instances of that Contact from the user’s Outlook, then deleting the millions of that Contact from CRM (which has taken a week in a bulk delete), then we’re going to turn on “platform traces” (requiring a registry change), then we’re going to reactivate syncing, and gather the logs, and send them to Microsoft.
I’ll be back when there’s a definite solution.
Updated with a definite solution:
For the sake of completeness and in order to help anybody else who experiences this...
This nightmare was resolved by installing CRM patch v8.2.13.21. [NB We had been on v8.2.2.112] As soon as the patch was installed, the system ceased generated all these Contacts. They stopped being generated to the second!
We're still cleaning up the mess of the unwanted 20 million Contacts which shouldn't be there. But at least the issue is fixed.
I think the lesson is to keep your CRM system up to date in terms of patching!
I faced similar issue in OnLine when we enabled outlook synchronization for Dynamics.
Even we had contacts been created randomly. If you look in advanced find for contacts Created randomly it should be created by System user.
There is user setting in CRM as below and I think in your case Automatically create records in Microsoft Dynamics 365 is set to YES
You will have to change this to No.
For other users you can use XRMToolBox plugin called User Setting Utility and there in you can see every user's personal setting as below
with the same XRM Tool Plugin you can bulk edit user personal setting as well
I'd like to set up App Insights on a .NET Core API project I have.
I've been following a couple articles, this simple one with setup steps here: https://learn.microsoft.com/en-us/azure/azure-monitor/learn/dotnetcore-quick-start
And the more in-depth: https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core
I have everything set up and registered correctly
But I can't get any data to show up, either in Azure or in Visual Studio's App Insights Search
The steps to setup seem pretty straightforward and I haven't missed any steps - any good reasons why no data is showing up?
As per your description, there seems no configuration error in your site since you can see the telemetry data is sent via visual studio output.
There are some things you need to check:
In application insights search:
1.please make sure the time range is selected as a proper value, like last hour or last 30 minutes.
2.For the types, select All.
And also note that, there is always some minutes delay for the data to be displayed on azure portal.
If you want to get more infor, then in appsettings.json, you should change Warning to Information
I have a basic VB.Net application that gets data from some websites and then send them to a MS-SQL database automatically. I have developed it as a desktop application with a WinForm front end with logs writing to the WinForm continuously.
Now, is it possible to convert the Winform to a Windows services so that I do not need to keep it opening in front of my PC and watching the logs, instead, it runs quietly in the background and the data gets logged into the system log viewer?
Many thanks!
In Visual Studio choose File->New Project and in the Windows templates you'll see Windows Service. Choose that option and then start migrating your code. If you kept most to all of your non-UI code in a separate DLL it will be easy because then you can have your service reference that library.
The following MSDN link has step by step instructions on how to get started with Windows Services but the answer is it not possible to convert your application but you can create a new windows service and copy your code across. This should be quite trivial.
If you have a specific interval to run the project, then you can use windows schedular to have the executable invoked as per your requirement and interval. However, as answered earlier, to convert your project to win services, you need to create the windows services from scratch and what you can do is, keep your business logic classes seperate and have objects created from the component classes.
We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.
Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.
SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:
Workflow instances are persisted in the content database
Communication with the user is through SharePoint tasks
Every workflow instance is tied to a list/library item
Tracking is not implemented
If these choices are to your liking then by all means use the SharePoint workflows.
If not then implement your own host and make your own decisions.
They are the same thing. The current Windows Workflow Engine was created for SharePoint.
Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.
Here is a link describing the upgrade in 4.0.
You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.
Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.
I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.
It's basically the same technology. If you know one you can easily work with / switch to the other.
When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)
Your SharePoint Server will act as a host for your workflows.
The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.
As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.
SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.
In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).
SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.
As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).
I'm planning to develop a timesheet system that requires users to fill out a form, submit, and requires manager approve/reject, and finally submit to finance. Since there's quite a bit of workflow, is WF a good tool for this kind of thing? I'm going to code it in ASP.NET.
Workflow would be a good fit for all process related code you need to write. So stuff like the submission, approval or rejection and handling the fact the it is dormant for an excessive amount of time.
A few things to keep in mind.
If you are going to use ASP.NET I presume the workflow will be hosted there. So you need to make sure the workflows can run after IIS recycles the AppDomain.
Think about whether to use WF4 or WF3. WF4 is a complete new animal and only in beta. WF3 was release as part of the .NET 3.0 release but has a limited future. It is sill there in .NET 4 and will still be supported bu the bulk of the work will be on WF4.