by community-syndication | May 12, 2007 | BizTalk Community Blogs via Syndication
This is the third post in my Commerce Server 2007 B2B Solution Development series and if you've been following the first two posts (1, 2), you'll remember that I like to "begin with the end in mind". In Commerce Server 2007 terms, this means figuring out how to map the XML produced by the Orders Receive Adapter (OrderGroupCollection schema) to something a little easier to work with as you integrate your Commerce Server orders into your ERP system.
BTW, this is one of the most widely asked questions I've seen in the past year and there's nothing in the Commerce Server docs to suggest how to use the XML produced by the Orders adapter.
The new Orders Receive Adapter produces a single message type which is used to periodically export order information from the Commerce Server Orders subsystem. This adapter is unique among the four new adapters in that it performs everything within a transaction, which allows roll-back in case of an error. The Orders adapter produces an XML document which conforms to the OrderGroupCollection schema as shown below from the BizTalk Schema Editor.
Since this schema was developed to match the Commerce Server Orders subsystem it’s unlikely that you’ll be able to use the XML produced by it “as is.” This is where the BizTalk Map comes in to play. In most cases, you’ll want to “normalize” the XML documents received from the Orders Adapter by mapping to some standard XML schema used by your organization. In our case, we normalize all inbound purchase orders (whether from an external trading partner or from Commerce Server) to an internal format that’s easier to work with and one which “fits” better into our existing BizTalk applications. This normalized XML sales order schema is shown below.
One of the challenges in mapping from the OrderGroupCollection schema is how to map weakly-typed (indexer) properties found in the various elements within the schema. Luckily, the BizTalk Mapper tool includes several functoids that make this process pretty simple. In the example below, the Equal functoid returns true if it finds a certain string in the WeaklyTypedProperty element’s Name attribute and the Value Mapping (Flattening) functoid will then map the Value attribute to the shipping_method_name attribute in the outbound schema. Using these two functoids, you can “look up” all the weakly-typed properties used in your Commerce Server application by their name and map them as needed.
Another challenge in mapping from the OrderGroupCollection schema is how to map the correct OrderAddress attributes, since the OrderAddress elements are located on the same level as the OrderForm they correspond to in the schema. This makes mapping using standard techniques very difficult but thankfully, BizTalk Server includes some advanced functoids created for just this kind of mapping challenge.
In the sample shown below, I’ve used the Database Lookup and Value Extractor functoids linked to the ShippingAddressId attribute to lookup all the required address information directly from the Commerce Server “transactions” database. Since the ShippingAddressID property is set in the Commerce Server web application and persisted to the “transactions” database, it should be present in all saved orders. A word of caution should be noted however. The Database Lookup and Value Extractor functoids call the database directly from the BizTalk map and as such, they could cause performance issues when used in a high volume scenario. Always test your BizTalk applications thoroughly before deploying into your production environment.
Obviously, mapping from the Commerce Server OrderGroupCollection schema directly to the schema used by your ERP system is "possible" but in my experience, mapping to a simpler XML schema (normalizing) and then to your final schema is much more effective. Remember, in BizTalk Server you can map on a Receive Port, a Send Port, in an Orchestration or in any combination of the three. This flexibility makes it possible to map from the OrderGroupCollection schema to just about any schema you require.
by community-syndication | May 12, 2007 | BizTalk Community Blogs via Syndication
It’s becoming more and more eminent to understand under which CLR version (1.0, 1.1 or 2.0) the BizTalk runtime, In-Process host is running. I’ve explained in my previous post the various factors that influence loading appropriate CLR versions and also how you can make use of the config file to force a specific version of CLR is always loaded.
There is one more query raised, what happens if you install .NET Framework 3.0 on your BizTalk server (both 2004 and 2006)? The effect of installing .NET 3.0 doesn’t introduce that much behavior difference when compared to installing .NET 2.0 on a BizTalk 2004 machine (built using .NET 1.1 with CLR 1.0). Because .NET 3.0 is still based on .NET 2.0 and shares the same compilers and Common Language Runtime (CLR 2.0). See the following posts from Somasegar and Jason Zanders (comments are more interesting on the both the posts)to see the effect of .NET 3.0.
With all this confusions around different versions of .NET and different versions of BizTalk and different Service Packs, there will certainly be a situation where developers and administrators need to figure out the version of CLR under which the BizTalk Runtime is running. This is where Process Explorer comes to our rescue.
Process explorer’s top window shows a list of currently active processes, and the bottom windows shows either the handles opened by the selected process or it shows the DLL’s and memory mapped files that the selected process has loaded. You need to set the appropriate mode from the menu item “View-> Lower Pane View”. In our case we need to figure out the version of Common Language Runtime core dll (mscorwks.dll) loaded into the BizTalk runtime process (BtsNtSvc.exe). So, we’ll set the “Lower Pane View” to DLL’s (or Ctrl + D).
Also, make sure the following columns are visible Description, Image Path, and Version. To do so, click on “View” menu and select “Select Columns” and in the “Process Image” tab select appropriate columns.
The following screen shot is taken from a machine running BizTalk 2006. You can see clearly from the bottom pane the version of CLR running is 2.0 and physical dll is loaded from the location “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll”. BTW, .NET 3.0 is installed in this particular machine, which also proves .NET 3.0 still uses CLR 2.0. In BizTalk 2006 box its quite straight forward it’s all .NET 2.0. Things will become more interesting in BizTalk 2004 scenario.
Nandri!
Saravana
by community-syndication | May 11, 2007 | BizTalk Community Blogs via Syndication
I’ve read the Team Foundation Server Branching Guidance several times but I still have some questions I’m hoping the development community at large can help answer.
The small team I lead does typical corporate development projects including data warehousing, business-to-business integration, e-commerce and intranet/extranet web applications. We develop all our corporate “applications” using Microsoft tools such as Visual Studio 2005 Team Suite, SQL Server 2005, BizTalk Server 2006 and Commerce Server 2007. Our development efforts are driven by both internal customers and external trading partners and all projects continue to “evolve” over time, adding new scenarios as the business continues to grow.
Although we don’t use this term, we “continuously integrate” these new scenarios into our TFS projects at a very rapid pace and deploy them on an “as needed” basis. We rarely “roll back” something that we have deployed and we tend to fix our “bugs” as we (or our internal or external users) find them. I believe this is a pretty typical corporate development scenario. What we need is guidance on setting up a branching/merging strategy that “fits” a corporate development scenario where “releases” are small and incremental (such as deploying a new SQL Reporting Service report or SSIS Package) and happen very often (sometimes several per week).
Today, we use a “branch per major release” strategy and only create a new branch when we need to temporarily maintain our “Release 1.0” code while deploying a “Release 2.0” to our users. After deploying the “Release 2.0” bits we discontinue supporting the “Release 1.0” branch. So far, we have never merged from branch to branch.
Questions:
1) Is this a legitimate branching strategy for a small corporate development team?
2) If not, how do we deploy a more traditional DEV/MAIN/PRODUCTION strategy without the “overhead” of merging almost continuously?
by community-syndication | May 11, 2007 | BizTalk Community Blogs via Syndication
I’ve read the Team Foundation Server Branching Guidance several times but I still have some questions I’m hoping the development community at large can help answer.
The small team I lead does typical corporate development projects including data warehousing, business-to-business integration, e-commerce and intranet/extranet web applications. We develop all our corporate “applications” using Microsoft tools such as Visual Studio 2005 Team Suite, SQL Server 2005, BizTalk Server 2006 and Commerce Server 2007. Our development efforts are driven by both internal customers and external trading partners and all projects continue to “evolve” over time, adding new scenarios as the business continues to grow.
Although we don’t use this term, we “continuously integrate” these new scenarios into our TFS projects at a very rapid pace and deploy them on an “as needed” basis. We rarely “roll back” something that we have deployed and we tend to fix our “bugs” as we (or our internal or external users) find them. I believe this is a pretty typical corporate development scenario. What we need is guidance on setting up a branching/merging strategy that “fits” a corporate development scenario where “releases” are small and incremental (such as deploying a new SQL Reporting Service report or SSIS Package) and happen very often (sometimes several per week).
Today, we use a “branch per major release” strategy and only create a new branch when we need to temporarily maintain our “Release 1.0” code while deploying a “Release 2.0” to our users. After deploying the “Release 2.0” bits we discontinue supporting the “Release 1.0” branch. So far, we have never merged from branch to branch.
Questions:
1) Is this a legitimate branching strategy for a small corporate development team?
2) If not, how do we deploy a more traditional DEV/MAIN/PRODUCTION strategy without the “overhead” of merging almost continuously?
by Richard | May 11, 2007 | BizTalk Community Blogs via Syndication
I’ve just finished reading a paper written by David Pallmann.pdf) (PDF) from Neudesic. Belive it or not (or even better check it out), it’s a short and understandable description of what an ESB is!
Neudesic sells a product called Cyclone which is something they call a ESB architecture and framework software and even if describing this product is the main purpose of the paper the first part deals with describing the basics of an ESB and try’s to “assemble a synthesis of popular ESB definitions”.
I’ve chosen a couple of parts of the paper that really appealed to me but I really recommend the full length version (only 8 pages!).
Defining the ESB
>
> * An ESB is a backbone for connecting and integrating an enterprise’s applications and services.
> * An ESB provides the necessary infrastructure to create a service oriented architecture.
> * An ESB is a convergence of EAI, MOM, and SOA concepts.
> * An ESB is based on open standards such as XML, SOAP, and WS-*.
> * An ESB provides intelligent routing, such as publish-subscribe, message brokering, and failover routing.
> * An ESB provides mediation, overcoming data, communication, and security differences between endpoints.
> * An ESB integrates with legacy systems using standardsbased adapters.
> * An ESB provides logical centralized management but is
physically decentralized.
> * An ESB is able to apply EAI concepts such as rules and
orchestrations.
> * An ESB is able to monitor and throttle activity as per a Service Level Agreement (SLA).
>
I never thought of an ESB as an convergence of EAI (Enterprise Application Integration), MOM (Message Oriented Middleware) and SOA (Service Oriented Architecture) concepts. But, ok, so what does the writer really mean by these concepts?
SOA makes loosely-coupled, decentralized solutions possible that are enterprise-ready and based on interoperable standards. EAI allows integration of any combination of systems, with sophisticated message brokering, message translation, business process orchestration, and rules engine processing. MOM provides intelligent routing such as publish-subscribe topical messaging and strong managerial controls over routing, auditing, activity monitoring, and throttling.
>
>
And why do we need a bus architecture on top of SOA, MOM and EAI?
Point-to-point architecture
works all right on a small scale, but its problems become
apparent when used at the enterprise level. If each system has to know the connection details of every other system, then each new system added increases the problem of configuration and management exponentially. This was the impetus that led us to hub-and-spoke architectures, which most EAI products use. This architecture was a vast improvement over point-to-point architectures, and each system needed to communicate with only the hub. In addition, the hub could provide excellent management features since it was a party to all communication. It only took time to reveal some shortcomings with the hub-and-spoke approach, and today it is often associated with concerns about scalability, single point of failure, and vendor lock-in.
>
> …
>
> Fortunately, there is a sound compromise to be found in the bus architecture, which provides the benefits of logical centralization but is physically decentralized. The bus architecture in earlier days was often used in message bus systems based on proprietary technologies, but an ESB implements this architecture using WS-* standards.
>
>
So using all three of them will make an ESB? Well, not really …
If combining disciplines was all there was to an ESB, we’d simply call it “consulting”. To properly leverage these disciplines they need to be combined in the right way through an architecture that lets their strengths shine and overcome their inherent weaknesses. Each discipline has some weak areas that the others help to resolve: SOA needs better enterprise manageability; EAI needs to become decentralized; MOM needs to get away from proprietary technologies. Combining these disciplines properly in an ESB overcomes these weaknesses.
>
>
I’d be very intreseted in comments of other artciles, papers and so on relating to the ESB concept!
by community-syndication | May 10, 2007 | BizTalk Community Blogs via Syndication
I’ve just finished reading a paper written by David Pallmann (PDF) from Neudesic. Belive it or not (or even better check it out), it’s a short and understandable description of what an ESB is!
Neudesic sells a product called Cyclone which is something they call a ESB architecture and framework software and even if describing this product is the main purpose […]
by community-syndication | May 10, 2007 | BizTalk Community Blogs via Syndication
One of the really cool features included in the Orcas bits is the integration between Microsoft AJAX 1.0 and WCF. My buddy Steve Maine has been doing an amazing job evangelizing this technology. One of the components that make possible the “WCF-Atlas”…(read more)
by community-syndication | May 9, 2007 | BizTalk Community Blogs via Syndication
I just noticed that the Professional BizTalk Server 2006 book is now available on Amazon.com.
I haven't had a chance to look at it yet, but the outline, comments, and blog posts all look very good.
by stephen-w-thomas | May 9, 2007 | Stephen's BizTalk and Integration Blog
The long awaited Professional BizTalk Server 2006 book is now available on Amazon.com.
I haven't had a chance to look at this one yet, but the outline looked very good.
I'll try to post an update once I get around to looking though it.
by community-syndication | May 9, 2007 | BizTalk Community Blogs via Syndication
Next Thursday night – (May 17, 2007) we are hosting an event in our Melbourne offices called “Integrating Track and Trace into your Enterprise System”. It’s a collaborative effort between:
and
to understand how you can use Microsoft technologies to do track and trace. For me, its’ about the BizTalk RFID platform.
The invite describes:
- B2B specialist knowledge to tackle the foundations of e-business and EAI with the leadership of Microsoft Gold Partner – Bryn Systems
- Wireless bar code application and RFID expertise from the leading Motorola business partner – Datanet
I’m certainly looking forward to the event, as it will be an opportunity to socialise with peers who have “track and trace” on their strategic agendas. We’ve put a lot of ground work to get to this stage, so I’ll let you know how it goes. Oh, by the way, let me know if you are keen to attend! 🙂
