by community-syndication | Dec 7, 2006 | BizTalk Community Blogs via Syndication
Getting external data into an InfoPath form is extremely easy and creating rich electronic forms is easy as well, so lots of power users and developers are using InfoPath to capture structured data. Publishing those forms is also very easy: in the InfoPath client, just click the Publish menu item and go through the wizard. Et voila, the form is ready to be filled out in a SharePoint document library by the end users. The fun starts when those power users or developers are not allowed to deploy directly to the production SharePoint servers: probably the locations of the external data is different on your development/test server than on the production machine (especially if you automatically submit data). In InfoPath 2007 and Microsoft Office SharePoint 2007 (MOSS 2007) this can be solved by using Universal Data Connection (UDC) files. The InfoPath knows where to find the UDC file (relatively to the location of the form) and the UDC file tells InfoPath where to data is located. So the location of the data is not stored anymore in InfoPath, but it’s stored in the UDC file. The result: you can change the location without having to change the InfoPath form.
This is all great if the people who create the InfoPath forms are making use of UDC files, if not … you can make use of a new Microsoft tool: the Server Upgrade and Migration Tool for Microsoft Office InfoPath. There are some other reasons why you could make use of this tool: backup/restore, upgrade from WSSv2, …
The Server Upgrade and Migration tool allows a SharePoint farm administrator to change hard-coded URLs in InfoPath form templates, UDC files, and content types to ensure that the form templates continue to work correctly in the following circumstances:
- When performing a gradual upgrade from Microsoft Windows SharePoint Services 2.0 to Microsoft Windows SharePoint Services 3.0 or from Microsoft Office SharePoint Portal Server to Microsoft Office SharePoint Server 2007.
- When migrating InfoPath forms and form templates from one Windows SharePoint Services 3.0 or Office SharePoint Server 2007 or Web site collection to another.
During a gradual upgrade, the Windows SharePoint Services 2.0 server is temporarily renamed. The tool can be used to change the following hard-coded URLs so that InfoPath forms on the renamed server continue to work during the upgrade process:
- Data connections to the local server contained in the InfoPath form template
After a site collection is upgraded, the tool is used again to change the URLs back to the original name.
The tool can also be used on a Windows SharePoint Services 3.0 server after content is migrated from one location to another to fix up URLs that may be broken by the move. Similarly, the tool can be used to fix up URLs when a backup set is restored to a new server or when an existing content database is attached to a new server. When the tool is run on a Version 3.0 Web application or Web site collection, the following are also updated:
- Data connections to the local server contained in data connection files in a data connection library
- URL to a form template contained within a content type
by community-syndication | Dec 7, 2006 | BizTalk Community Blogs via Syndication
[Via Renaud Comte, aka CAML Boy] I haven’t tried this tool myself but it looks like a potential must-have-tool for every SharePoint developer’s/administrator’s toolbox: SharePoint Inspector [download here].
by community-syndication | Dec 7, 2006 | BizTalk Community Blogs via Syndication
Because the documentation is so vast on this, I thought I write a few lines about it.
When specifying a static ack it has a space for both positive and negative values. Unlike all of the other places in the accelerator where you will put either the decimal value or the hex value, in these fields you actually need to past the actual character. A recent client required that a ack be sent back (06 0x06) and that a nak be sent in error (21 0x15). We tried everything until we actually copied from ultraedit into the fields the actual character.
It shows up as a box in the Configuration Explorer, but it sends the SB CR and EB around the character that you have defined in those fields.
by community-syndication | Dec 7, 2006 | BizTalk Community Blogs via Syndication
Once in a while I get the remark that there are no document-level templates available in Visual Studio Tools for Office 2005 SE (VSTO 2005 SE). Typically people that used to work with Visual Studio Tools for Office 2005 are worried since they can’t find their beloved templates for creating Word documents, Word templates and so on in Visual Studio. Actually the download page for VSTO 2005 SE gives the answer/solution:
Note that if you install on top of Visual Studio 2005 Professional, no document-level customizations or other functionality that is part of the full version of Visual Studio 2005 Tools for Office (VSTO 2005) is installed. VSTO 2005 SE adds only the application-level features listed in the feature highlights section above. If you install on top of one of the Visual Studio Team editions or Visual Studio 2005 Tools for Office, you will have VSTO 2005 project types available side by side with VSTO 2005 SE projects.
To summarize: if you install VSTO 2005 SE on top of a clean VS 2005 Professional, you won’t have the document-level templates. If you want to have them you need to have VS 2005 Team Suite/Team Edition or you need to install the previous version of VSTO: VSTO 2005. So VS 2005 Professional + VSTO 2005 + VSTO 2005 SE will give you the document-level templates!
by community-syndication | Dec 6, 2006 | BizTalk Community Blogs via Syndication
There are certain myths that float around the IT industry that defy rational thought. I was recently exposed to one of these myths in a conversation and so I thought I wouldblog about it in the hopes that I could dispell it somewhat.
Risk adverse organisations will often say that they want the latest version minus one (n-1). The idea is that by going with the latest they are somehow exposing themselves to some sort of increased risk of newly introduced bugs. The implied assumption is that older versions are more “stable” and therefore less risky.
This is completely wrong. The code base of BizTalk 2006 is built directly on top of the BizTalk 2004 code base. So BizTalk 2006 = BizTalk 2004 + All BizTalk 2004 Hotfixes + 2 years worth of design improvements.
So by going with BizTalk 2004, you are depriving yourself of both the design enhancements of the newer version but you are also getting a inferior code base. Now someone somewhere will take that last sentence to mean “BizTalk 2004 is a inferior product”. Thats not what I said. I said, BTS2004 is an inferior CODE BASE in COMPARISON to BTS2006.
I’ve also encountered customers who apply the same thinking to Service Packs. They don’t want to apply the latest for some perceived added risk. My response to this is that you are far more likely to hit bugs in the down level version than you are to hit a problem CAUSED by the application of a service pack. Maybe this perceptoin comes from the bad old days when the engineering that went into service packs was less robust. I don’t know. But what i do know is that, service packs should be applied asap to lessen the risk of hitting bugs. To put that in other words, Service packs lessen risk.
While we’re on that topic…BTS2004 SP2 is highly recommended but be aware that the install modifies the database schema for the message box and tracking databases. If you have large amounts of data in the tracking database, the application of the service pack could take a looong time. One of my customers reported 12+ hours. So this is something you will want to test before trying to apply during a weekend maintenance window. And when you do test this, make sure the test system you are using actually will reflect what you have in production. That is, if you production tracking database is 5 GB, then your test system should have 5 GB in the tracking database also. Or alternatively, archive tracking first before the upgrade and not have the problem.
I’m a big fan of having an identical UAT environment which you can install independantly for production and then do a promote / demote switcheroo and thereby cut over to the new version with the flick of a switch. No risk of borking production during a maintenance window if the UAT(the new production)was prepared and tested earlier. I’ll try to make a comprehensive post on this at a later date.
by community-syndication | Dec 6, 2006 | BizTalk Community Blogs via Syndication
On this post Dare summarized an interesting discussion about REST and Message Security
by community-syndication | Dec 6, 2006 | BizTalk Community Blogs via Syndication
Introduction
Recently, a company in the process of implementing BT 2006 within their enterprise asked me for a recommendation regarding best practices for a pre-existing usage scenario they were seeking to accommodate using BizTalk. This company receives, on a reoccurring basis, a variety of disparate inbound flat file business documents which, at present, are processed into […]
by community-syndication | Dec 6, 2006 | BizTalk Community Blogs via Syndication
I was recently helping one of our clients parse a record-based flat file where the records are mostly positional identified by a tag. The issue was that the flat filewasa credit card transaction log where each record, identified by a tag, is a sibling to the other records with no specific order in which the […]
by community-syndication | Dec 6, 2006 | BizTalk Community Blogs via Syndication
After reading Charles Young’s fantastic post today on BizTalk transaction compensation, I was finally inspired to write a post that’s been on my blog “to do” list for 7 months. Specifically, I wanted to demonstrate simple compensation handling, and dealing with loops and transactions.
I’d like to walk through a simple solution I just built and demonstrate the transactional considerations. The first thing to show here is that data (variables, messages) manipulated within an atomic scope do NOT have their changes committed unless the atomic scope successfully completes. In the picture below, you’ll see a very simple orchestration I built that receives a message, sets a value for a variable (“Status”), jumps into an atomic transaction, does a calculation, updates the “Status”, and finally completes by writing the “Status” value back out. Basically what I’m trying to show is that the variable “Status” may have gotten changed by the action in the atomic scope, however, if the scope fails for any reason, that change isn’t committed.
I’m using the (now-Microsoft) tool DebugView to view the Debug.WriteLine statements embedded in my orchestration. When I pass in a simple message, you see here that indeed the value is initialized (“Starting”) and changed by the atomic transaction (“Updated”).
If I pass in a bad message (in this case, dividing by 0), then the orchestration is suspended and the compensation code does NOT fire. Why? Compensation only fires for committed transactions, and since an operation within the atomic scope failed, there’s technically nothing committed, so nothing needs to be compensated. Now what if I wrap the atomic transaction in an long running (LR) transaction so that I can catch any exceptions and gracefully handle it?
Now, when I run this process, the exception block catches the error, and I continue on in my orchestration. As you’ll see here, because the atomic transaction did not commit, the “Status” field change was not persisted.
What happens if we instead cause an exception AFTER the atomic transaction has completed?
You’ll see here that the step following the atomic transaction raises an exception. What do you expect to happen when I drop a standard (valid) message into this orchestration?
The compensation code did NOT fire since I didn’t do anything to trigger it. All that happened was that the shapes in the Exception block were processed. Let’s force a compensation to happen. We could, in the Exception block, use a Compensation shape and explicitly compensate the atomic transaction. But, what if I had 4 atomic transactions in there and didn’t want to explicitly roll back each? What I can do is compensate the Long Running transaction, which in turn will execute the compensation code for each contained transaction in reverse order. We’ll see more of that in a second. My compensation now looks like this:
If I spin up the orchestration now, you can see here that the Exception block AND compensation code both fire. Sweet.
What happens if I add a second atomic scope to our LR transaction and raise the exception after the new transaction?
Without changing anything in the LR transaction, it went ahead and executed compensation on both transactions in reverse order.
The last thing I want to show here (and probably the neatest), is something Charles mentioned in passing in his article. I like to show this when I teach BizTalk workshops and it always amuses folks. What happens if I’m executing transaction in the confines of a loop? Is BizTalk actually smart enough to keep track of this and handle it appropriately? I’ve modified my orchestration to now contain a Loop shape and cycle through 5 times. On each pass, it executes the atomic transaction. Following the loop, I raise an exception. I still haven’t changed anything with regards to compensation in the LR transaction.
Any idea what you’ll see when I run this? As you’ll notice below, it goes ahead and executes each transaction, and exception is thrown and caught, and each of the looped transactions have their respective compensation code called. Neato. I’m always impressed to see that.
There you go. Read Charles’ article for significant more depth on the topic, but hopefully this provides a more simple take on a fairly complex process.
Technorati Tags: BizTalk
by community-syndication | Dec 6, 2006 | BizTalk Community Blogs via Syndication
Do you get panic attack by hearing this jargon words in Biztalk world?
No worries! They are quite simple.
They are just design patterns, the way you implement your business process.
1. Parallel Receive
Condition: you wait for all the messages to come into your business process before the processing starts. Example: If you need to process something after receiving quotation (message) from all your manufacturers.
Key steps in your orchestration
* Drop Parallel action with 2 or more Receive shapes in the beginning.
* Activate = True in all the receive shapes
* Initializing Correlation Sets = “somecorrelationset” in all the receive shapes. (You need to define a correlation set with an element unique across all the messages you receive).
2. Sequential Receive
Condition: Either you receive same type or different type of message one after the other; you need to wait until you receive some kind of control message to say “That’s the end”, or keep receiving “n” number of messages.
Key steps in your orchestration
* Set Activate = True in the first Receive Shape, Initializing Correlation Sets = “somecorrelationset” (You need to define a correlation set with an element unique across all the messages you receive).
* Set Activate = False in the following receive shapes, Following Correlation Sets = “somecorrelationset”, and
* Put a Loop across Receive shape. Terminate the loop based on your condition either after receiving “n” number of messages or after receiving the control message.
