… to start thinking like a SharePoint person.
I see paradigm misalignments all the time, where really bright people develop BizTalk solutions using object-oriented principles, just as they would if they were developing say a typical .NET application. However, as BizTalk is a message-oriented paradigm, thinking like an OO person will generally yield less agile, less scalable, and unnecessarily complex solutions.
In my case, I was crossing the BizTalk/SharePoint boundary, but my initial direction didn’t reflect that transition.
I was working on an order process, and we needed to involve humans in case there was something wrong with the order and intervention was required, a typical repair-and-resubmit pattern. To interact with humans, we used a combination of SharePoint (as a host) and InfoPath (as an editing environment). The idea was BizTalk writes out orders requiring intervention to a forms library, users click a link there, and edit the order in InfoPath. When ready, the user clicks “re-submit” and the order is re-processed. Implementing this is no big deal, and as InfoPath works well with Web services, a Web service call sits behind the “re-submit” button. The next step is that we now need to delete the item from the forms library. OK, thinking like a SOA/Web services person, I thought I’d do that by calling the SharePoint Web service. However, after some investigation, it turned out that this was actually two Web service calls, one to get the item ID (which is required in order to delete the item) and another to do the actual deletion.
This path now meant that when the user presses “re-submit”, three Web service calls occur. This immediately raised the following concerns:
· User experience: how much time will pass from the time the user presses the button until the action is complete?
· Latency: the client network is sometimes slow, if there are three calls, we have three chances to time-out
· Transactional integrity: we need to think about cases such as the order is resubmitted, but the deletion from SharePoint doesn’t occur (timeout, network failure, server down, etc). Now there’s a risk of duplicate orders
Clearly, although the solution met the functional requirements, this seemed like a sub-optimal approach that was *fraught* with risk.
I started exploring ways to optimize the actions behind the button. It was a call with one of Neudesic’s SharePoint experts that turned on a light for me. Apparently, “the SharePoint way” would be to save out the form, then let something else happen. Why couldn’t I do the same?
So, the revised solution is:
· BizTalk writes out an order (XML document) to a SharePoint forms library
· There is an “OrderStatus” SharePoint meta-data column, when first written out, this is set to “INTERVENTION”
· User opens a “Orders for Review” SharePoint view (which only shows items that have an order status of “INTERVENTION”)
· User edits order in InfoPath. When done they hit “re-submit”
· Behind the button, the order status is changed to “RESUBMIT”, and the form is saved back to the same form library
· A BizTalk receive location is polling the form library using a second SharePoint view (“Orders to be processed”) that only shows forms with a status of “RESUBMIT”
This now means:
· Perceived latency after pressing the re-submit button dropped from “could be 20 or 30 seconds, if everything works” to “sub-second response”
· Everything is asynchronous and loosely-coupled now, resilient to outages or failures
· The revised approach leverages the environment it is running in (message-oriented inside BizTalk, document-centric inside SharePoint)
· The InfoPath form becomes extremely simple
· I have actually managed to use the word “fraught” in a blog post J
And, as an added bonus…. We will have different form libraries, as order editing will be done by the people in a region. With this approach, deployment becomes simpler as we’ll be changing endpoints in BizTalk and adding views in SharePoint, as opposed to coming up with a strategy to manage endpoints used in code-behind an InfoPath form.
As we move further into a services-oriented world where creating solutions increasingly means tying services and applications together, it is important for us to remember that there are environment boundaries, and sometimes those are also paradigm boundaries. If a solution you’re working on seems like it’s overly complex, then perhaps you’ve crossed an environment boundary but brought your paradigm with you. Step back, take a deep breath, and re-evaluate your approach from a high level.
This may be obvious to many, but I thought I’d blog about this real-world experience for the benefit of SOA/Web service people that would, because it would be perfectly natural for them, end up going down the “do all the calls behind the button” path.