Search results for 'app:weblogs' matching tags 'Workflow', 'VB', and 'WCF'

Nederlandse CodeCamp 2009

Maurice — Mon, 19 Oct 2009 05:00:00 GMT

Op 21 november 2009 organiseren de SDN, Stichting dotNed en VBcentral samen het derde Nederlandse Code Camp. Dit is een dag lang met code, code sharing, freaking en gezellig samenzijn. Een evenement door ontwikkelaars, voor ontwikkelaars. De regie ligt voor een belangrijk deel bij de deelnemers! Het aantal plaatsen voor deelnemers is wel beperkt tot maximaal 150. Wacht dus niet te lang met beslissen want voor je het weet is er geen plaats meer. Vergeet bij je aanmelding niet op te geven welke onderwerpen je interesse hebben. Bovendien nodigen we iedereen graag uit om zelf een sessie in te vullen.

Op de website, www.codecamp.nl, vind je meer informatie en kan je je aanmelden.

Using a TransactionScopeActivity with a WCF ReceiveActivity revisited

Maurice — Tue, 10 Mar 2009 05:00:00 GMT

Last year Marcel and I worked on a problem using a TransactionScopeActivity inside a WCF ReceiveActivity. I blogged a number of time about our finding, for example here.

Last week I heard from Marcel that a hotfix was finally available that solves this problem. He blogged about it here. Great work to see there is a fix for this serious problem.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Looking back at the MVP Summit

Maurice — Sat, 07 Mar 2009 06:00:00 GMT

Last week lots of MVP, myself included, where in Redmond visiting Microsoft on our yearly MVP pilgrimage. The MVP Summit is always a great event. Not only do we get to talk to the MS team members who actually design and build all the software we love and use but we also get to meet each other. And with MVP’s being located around the world that is kind of rare as well.

Despite this being a great event I still have very mixed feelings about this last MVP summit. The problem isn’t the events itself or the people I met, that was al great . No the problem was in some of the technological decisions made in product groups. Unfortunately I can’t divulge details yet because I have signed an NDA but as soon .NET 4.0 as beta 1 is made public I will be able to blog about some of these decisions. And rest assured I will!

The reason we really need to is the way these important changes are communicated. Or should I say not communicated. Some very important changes where not communicated at all and could only be derived by bullet points missing from PowerPoint slides. Only when directly asked about the missing bullet point would someone say “Yes that is right, we decided to …. NDA … because … NDA …”. Sorry about the NDA part .

I can only say that these decisions are a big problem and I know several MVP’s who decided to skip other sessions on the same product as a result. I didn’t, as far as I am concerned ignoring a problem is not going to make it go away, but I really think this product team needs to reevaluate this decision and the general future trend.

Despite this hiccup I am very exited about lots of the things I got to see and am really looking forward to .NET 4 and Visual Studio 2010. Now if we only could have a beta today . When we will have a first beta is still a big question though. If a date was announced I missed it, the best I heard was a quarter and is quite a time span.

Enjoy.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

PDC session download

Maurice — Sat, 01 Nov 2008 05:00:00 GMT

Want to download and watch all PDC content? Then there are a couple of ways to get at them. The official way if to go through the session agenda at the conference site. See https://sessions.microsoftpdc.com/public/timeline.aspx. You see all sessions but it takes a bit of work. Another nice way is through Channel 9 by using the following feed: http://channel9.msdn.com/posts/pdc2008/RSS/?tag=videos.

But the best as far as I am concerned is using the list compiled by Greg Duncan. Check this list http://coolthingoftheday.blogspot.com/2008/10/pdc2008-quick-video-link-list.html. And it even has the Visual Basic source code used to generate the list

Enjoy the videos!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

A bit more about using TransactionScopeActivity within a ReceiveActivity

Maurice — Tue, 16 Sep 2008 05:00:00 GMT

Part 1
part 2
Part 3
Part 4

You may recall my previous posts about using the TransactionScopeActivity within a ReceiveActivity and all the nasty issues we ran into. Just in case you want to read them again: one, two and three.

As it turn out this is an intentionally not supported scenario at the moment. If we read the docs for the ReceiveActivity we can find the following note:

To ensure that persistence performs properly and does not persist transient messages, make sure that child activities of the ReceiveActivity do not persist by themselves. This can occur if the child activities go idle when a persistence provider was created with UnloadOnIdle set to true, for instance.

The note uses the UnloadOnIdle as an example but the persistence part is just as much true for the TransactionScopeActivity as this persists the state. Of course there is no similar warning in the TransactionScopeActivity docs and the activity validation fails to warn us either so there is definitely some room for improvement here.

But rumor has it that this improvement is coming The rumor says that not only will we be able use a TransactionScopeActivity inside of a ReceiveActivity but we can even go a step further in being able to flow a transaction from the client through the WCF request into the workflow and have the TransactionScopeActivity participate in the same transaction. Nice but I guess we will have to wait for the PDC before we get all the details.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Red Gate to continue development of .NET Reflector

Maurice — Wed, 20 Aug 2008 05:00:00 GMT

.NET Reflector, by Lutz Roeder, must be one of the most useful tools I have when developing .NET code. Usually it is the first thing I install right after Visual Studio not even waiting until I need it because I know I will.

So the big news is that Red Gate, makers of the Ants profiler and lots of other tools, are taking over from Lutz Roeder and will continue developing .NET Reflector. Interesting move and I hope this means a bright future for the .NET Reflector.

Visual Studio 2008 Service Pack 1 available

Maurice — Mon, 11 Aug 2008 05:00:00 GMT

It is available from the subscriptions download at http://msdn.microsoft.com/en-us/subscriptions/default.aspx

Get it while it is hot

Enjoy!

More on using a TransactionScopeActivity within a ReceiveActivity

Maurice — Fri, 08 Aug 2008 05:00:00 GMT

Part 1
part 2
Part 3
Part 4

In a previous blog post I write about what happens when you place a TransactionScopeActivity within a ReceiveActivity and an exception occurs that is supposed to roll back the transaction. In short the story was very bad and we could come up with only a partial workaround, not a pretty sight.

But there is more to it than just that little horror story. Suppose you do the obvious and place the a TransactionScopeActivity within a ReceiveActivity and no exception occurs. Say like the workflow below, please note that the codeActivity1 only sets the return value and causes no error.

Now the transaction is committed and the WCF call returns perfectly normally so everything is good right. Well not quite

The obvious first point is that the TransactionScopeActivity serves no real purpose. After all if it isn't allowed to fail under any circumstances why bother with it in the first place. Well ok there is the point of doing several updates as a single transaction so other users cannot see a partially committed order but that is about it.

But that is actually the least of my worries as there is a far bigger issue to worry about and that is called workflow persistence.

Yes that is right. After all when we are using a TransactionScopeActivity workflow persistence is mandatory. The TransactionScopeActivity is decorated with the PersistOnClose attribute so the state of the workflow will be persisted as soon as the transaction is complete. And normally that is a good thing but in this case it is the cause of the second problem because this is still inside the ReceiveActivity. So basically we are storing the workflow state as it is just before returning an answer to the client. Now if everything is running fine that won't matter because the workflow will continue until it is finished and everyone is happy. But suppose the workflow host terminates before the workflow is finished? In this test I added the DelayActivity, and set UnloadOnIdle to false so it doesn't persist the state, giving me the opportunity to kill the workflow runtime. Now if I restart the runtime It is going to reload the last state of the workflow and continue from there. And guess what it's going to do first? You guessed it: it is going to send the response to the client for a second time. Of course the client is no longer around and that action fails with an InvalidOperationException with message "Workflow unloaded between request & response."

I guess the message is not entirely correct as it should say "Workflow reloaded between request & response." but it's close enough.

The bottom line is the workflow terminates unless you specifically allow for this to happen and catch the error.

So basically we have a choice between putting the TransactionScopeActivity inside a ReceiveActivity, not being able to throw an error and having a restore problem, or putting the TransactionScopeActivity around the ReceiveActivity, something that only works with a sequential workflow and an initiating ReceiveActivity as I described in the previous post.

I guess these options make me pretty unhappy .

Enjoy your workflow transactions!

Using a TransactionScopeActivity with a WCF ReceiveActivity

Maurice — Wed, 06 Aug 2008 05:00:00 GMT

Part 1
part 2
Part 3
Part 4

I got an email from a friend last week asking about using a ReceiveActivity and, while receiving, using a TransactionScopeActivity to transitionally save some data in a database. Seems like a common enough scenario right? Well he was having some problems. If everything worked and the transaction succeeded everything was fine and the answer came back. But if an exception occurred and the transaction was aborted be was receiving a real weird error:

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Workflow service unexpectedly unloaded from memory while executing a ReceiveActivity. Make sure that the the workflow does not contain any blocking activities within a ReceiveActivity. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.InvalidOperationException: Workflow service unexpectedly unloaded from memory while executing a ReceiveActivity. Make sure that the the workflow does not contain any blocking activities within a ReceiveActivity.).

If we where to believe the message there was a blocking call, something there most certainly was not!

And to make things more confusing, if we removed the TransactionScopeActivity and just let the exception occur it would bubble back to the client just as it was supposed to. So what gives?

Well a lot of people looked at this and in the end we declared this a pretty bad bug. Mind you our words not those from Microsoft. But we did find a workaround. So lets take a look at a repro and how to fix this. My original test workflow looked like this:

I receive a WCF request, start a transaction, determine the return value in a code activity, throw an exception and return. Seems reasonable right? Well I thought so but it produces the error claiming there is a blocking statement. While tracking this Marvin actually noticed that the workflow idle event was raised! Excuse me, a workflow is becoming idle to undo a transaction sounds kind of wrong. And of course when a TransactionScopeActivity is used in a regular workflow, ie non WCF call, there is no Idle event.

A partial solution

So the way to get this to work is create the following workflow:

So instead of creating a TransactionScopeActivity inside of my ReceiveActivity I am doing it the other way round. Sounds kind of weird right? Well I think so but it does do the right thing as it returns the correct fault information to the client and then undoes any transactional work done.

So why does this workaround work in this case?

The ReceiveActivity has its CanCreateInstance property set to true so this is the request that actually creates and starts the workflow. This means that the workflow is created and starts executing from the top. Yes that is right, it starts from the top, not from the ReceiveActivity so any activities before that are also executed. I suppose that potentially opens a can of worms but we will leave that be for the moment. In this case the WCF request is received, this starts the workflow, this in turn starts the transaction, the message is received and processed and the transaction either commits or, like in this case, rolls back.

How about a non creating ReceiveActivity?

Well I am afraid no luck there as this workaround isn't going to work then. The problem is that we start a transaction before we start waiting for the additional WCF calls and the TransactionScopeActivity has a a TimoutDuration. So in all likelihood the transaction timeout will occur before the message is received and this effectively cancels the ReceiveActivity meaning it cannot receive the message.

I think this is a pretty major problem with the way WF and WCF work together. After all transactions a an essential piece of business applications and not being able to use them inside of a WCF request is a deadly sin.

Enjoy with care

CodeCamp 2008

Maurice — Sat, 02 Aug 2008 05:00:00 GMT

Afgelopen jaar hebben we het eerste CodeCamp in Nederland georganiseerd en dat was een groot succes. De meeste deelnemers vroegen om meer, sommige zelfs om een CodeCamp per kwartaal of een heel weekend lang. Nou hebben we dat laatste nog niet gedaan maar we zijn wel aan de slag gegaan om een nieuw CodeCamp te organiseren. Als datum hebben we zaterdag 6 september gekozen. Gelukkig waren Microsoft en Class-a behulpzaam en kunnen we, net als vorig jaar, weer in het Microsoft Innovation Center in Barneveld terecht. Een mooie datum en locatie om uitgerust van de vakantie een hoop kennis uit te wisselen.

Het programma staat nog niet helemaal vast, hou daar de website voor in de gaten, maar je kan er ondermeer de bekende Nederlandse sprekers verwachten. Uiteraard kan je zelf ook nog een sessie voorstellen dus als je een idee hebt voor een leuke sessie laat het dan zo snel mogelijk weten.

Dus zet de datum vast in je agenda en meld je zo snel mogelijk aan op de website www.code-camp.nl.

Het CodeCamp is een gezamenlijk initiatief van de SDN, de stichting DotNed en VB Central.