I'm just learning about using state machines in WF. I'm wondering if I can have multiple exit states? The use case would be a single entry state which would end up in one of multiple exit (terminal/final) states. E.g. lets say the object is an order. The entry state would be 'Pending' but it could end up in one of two states (after some processing): 'Shipped' or 'Canceled'. Is this possible or does a state machine have to have one terminal state?
I ended up just doing an experiment and WF does in fact support multiple terminal states (at least 4.5 does). I had a state machine setup with a single entry state (Opened), then it transitioned to three final states (Closed, Faulted, Canceled). It worked great.
Related
Consider for example this modified Simple TCP sample program:
How can I display the current state of the program like
Wait for Connection
Connected
Connection terminated
on the frontpanel, depending on where the "data flow" currently is.
The easiest way to do this is to place a string indicator on your front panel and write messages to a local variable of this indicator at each point where you want to see a status update.
You need to keep in mind how LabVIEW dataflow works: code will execute as soon as the data it depends on becomes available. Sometimes you can use existing structures to enforce this - for example, if you put a string constant inside your loop and wire it to a local variable terminal outside the loop, the write will only happen after the loop exits. Sometimes you may need to enforce that dataflow artificially, for example by placing your operation inside a sequence frame and connecting a wire to the border of the sequence: then what's inside the sequence will only happen after data arrives on that wire. (This is about the only thing you should use a sequence for!)
This method is not guaranteed to be deterministic, but it's usually good enough for giving a simple status indication to the user.
A better version of the above would be to send the status messages on a queue or notifier which you read, and update the status indicator, in a separate loop. The queue and notifier write functions have error terminals which can help you to enforce sequence. A notifier is like the local variable in that you will only see the most recent update; a queue keeps all the data you write to it in the right order so would be more suitable if you want to log all the updates to a scrolling list or log file. With this solution you could add more features: for example the read loop could add a timestamp in front of each message so you could see how recent it was.
A really good solution to this general problem is to use a design pattern based on a state machine. Now your program flow is clearly organised into different states and it's very easy to add in functionality like sending a different message from each state. There are good examples and project templates for these design patterns included with recent versions of LabVIEW.
You should be able to find more information on any of the terms in bold in the LabVIEW help or on the NI website.
Problem: I created 10 AlwaysOn Availability Groups with SQL Server without a problem. Suddenly, it stopped worked and I kept getting this ONLY on the "create the listener" part:
Msg 19471, Level 16, State 0, Line 9
The WSFC cluster could not bring the Network Name resource with DNS name 'L_MyListener' online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information.
Sometimes I also got Msg 19476. This was all maddening because one moment I was creating listeners and availability groups, feeling like a guru, and then everything stopped and I lost hours of time.
So how do you solve this? Of course, Microsoft's own suggested text in the above error description was NOT helpful.
Apparently, each listener is really creating a mini "computer" in Active Directory if you look. And... here's the kicker, a domain user can only join a computer to a domain a limited number of times and that default is 10. Who would have thought that adding listeners equates with joining users to a domain!???! Microsoft really should have made this listener thing more intuitive, at least in their description text of possible problems.
Well, on your Domain Controller, open ADSI Edit, configure it the first time to look at your default naming context of your domain, like "DC=yourname..." with the CN= rows below that. Now, right click on the "DC=" line, choose Properties and navigate down to ms-DS-MachineAccountQuota and increase the limit from 10 to something else like 100.
You may need to run "GPUPDATE /FORCE" on the SQL Servers where you want to try again to add the listener. You may also have to clean up the mess it left (i.e. delete and restore the bad attempt at setting up your group and listener) before you try again.
With SQL Server 2016 supposedly going to require each database be in its own group, with its own listener, people will hit this limit of 10 quite easily!
I hope this helps you. If so, please mark this as the answer on the left. Of course, there are other reasons why people may get this error, as in the Microsoft error now but this whole post is for people who had it working just fine and then suddenly it stopped.
I'm planning on developing a Monopoly game using a Console application in VB.NET, but with a separate GUI (probably a Forms application) that displays the state of the Monopoly board based on the information in the Console application, so that it can be ignored or used as the players wish. I've been looking into ways of sending information between two programs, and came across Pipes, except they seem complex and I'd like to use a different method if I can avoid it. The following is the methodology I'm currently considering to send information - I'd like to know if there is any way I could improve this methodology, or if you think it's completely stupid and I should just use Pipes instead -
Program 1 is the Console application which controls everything: the state of the game depends on the Console. Program 2 is the GUI/Forms application which follows instructions sent by Program 1 and displays the board accordingly. Program 1 and Program 2 communicate using two text files, Command.txt and CommandAvailable.txt. When something changes on Program 1 - e.g. a player makes a move - a command string is made and added to a queue. Program 1 continually checks CommandAvailable.txt to ensure that the file is empty, and if so, it clears Command.txt and then appends every command string in the queue to Command.txt. When it has finished, arbitrary text is added to CommandAvailable.txt, e.g. "CommandAvailable".
Program 2 continually checks CommandAvailable.txt until it is not empty, meaning that Program 1 has added at least one command to Command.txt. Program 2 then reads every instruction on Command.txt and adds it onto a queue on the other side. CommandAvaiable.txt is then cleared, which will permit Program 1 to add more Commands to Command.txt (because it only adds commands when CommandAvailable.txt is empty and hasn't already been marked by itself.) A separate thread on Program 2 empties the queue of command strings, parses them and executes them.
For example, in the Console, Player 1 may move to Trafalgar Square (or whatever the square would be called.) Program 1/Console would add the Command "move player1 trafalgar_square" to the queue, then check CommandAvailable.txt, and if it is empty, add all the commands in the queue to Command.txt. Program 2/The GUI would check CommandAvailable.txt and as it had been marked by Program 1, read the command, add it to the queue, and then move a picturebox that represents Player 1 to a square.
Please let me know if you think this methodology could be improved, or if you think it's simply stupid and there are far better alternatives or that I should just use Pipes instead. I'm going to be using VB.NET.
I am trying to create a workflow in sharepoint that has multiple approvals.
So there is conditonal logic that says if Person A accepts the proposal continue on to Person B approval if person B approves move on to Person C etc etc.
I have my logic for how the workflow should run but I am running into problems with SharePoint Designer 2010. Apparently each approval process that you add to a workflow adds something like 1100 nodes of complexity. The sharepoint default setting is set to I think 5000 nodes. My workflow has 12 approval processes so it will not publish. I have run some powershell scripts that are supposed to increase the complexity of workflows sharepoint allows but its still not working.
Is there a way to do this without so many approval processes and I don't really want to do a custom process but if that's my only option I might have to.
I ran into the same problem while developing a workflow. The only solution I came up with is to wait for the approval status to equal 'approved' and then set a column in your list to give an indication that it is completed. i.e. a column named first_approval_complete.
when your first approval reaches the 'approved' status, set that column to equal 'YES'
Then have another workflow that is set to 'run on item change' that begins with an if statement that checks if first_approval_complete is equal to 'YES'.
A little bulky, and makes each workflow a tad slower, but you can have an infinite number of approvals if they are all serial.
I'm confused. I'm an avid reader of several Sharepoint related Blogs and everybody says "don't use State Machine Workflows in .NET 3.5 anymore - they will not exist in .NET 4".
Reading up on the topic, .NET 4.0 does not support State Machine Workflows, but uses Flowchart WFs instead. Fine.
Now there is the Platform Update 1 - which introduces State Machine Workflows again. Also the announcement about the "new" state machine functionality doesn't say much about the why - seems like we have State Machine WFs again.
My question: Did Microsoft add state machine workflows back into the mix or is this a totally "new" state machine workflow activity (relating to compatibility). Was this move due to customer pressure of people complaining not having state machine workflows anymore? I'm basically looking for some kind of explanation of why there suddenly are state machine workflows in .NET 4 (with Platform Update 1). And: Will they stay (.NET 5) or is this a temporary move?
PS: Also take a look at the official State Machine Guidance Whitepapers, they basically still say if you are using state machine's in 3.5 - use Flowcharts now.
The StateMachine in WF4 is similar to the one in WF3 but WF4 is completely different so the differences are there in the state machine as well.
We wanted to ship a the StateMachine in WF4 but had to cut it in order to make the release date. Our plan was always to ship it as soon as possible.
As for the StateMachine Guidance Whitepaper - it just never got updated. I'll see if we can take care of that now.