by community-syndication | Mar 5, 2006 | BizTalk Community Blogs via Syndication
Last week I was in Redmond for QuickLearn’s BizTalk Server 2006 Deep Dive. It was great to get a dedicated week of time to look at BizTalk 2006. While the core of the product remains the same, it’s great to see the new features. I think everyone will be pleased with the new product! It’s coming soon…and hopefully I’ll be able to find some time to get out a few blog entries! One quick note, if you haven’t looked at the SDK that comes with any of the Beta’s for BizTalk 2006, please do so. Along with the existing SDK, Microsoft has also provided several scenarios that are full applications…not just simple examples! This is a great resource for developing Enterprise Applications.
Jon Flanders is now with QuickLearn and taught part of the BizTalk class. I would recommend every BizTalk developer bookmark his blog site: Mastering BizTalk Server.
by community-syndication | Mar 4, 2006 | BizTalk Community Blogs via Syndication
OK, David’s been a really lame blog poster (as in more than 6 months not posting!!??). I guess I could use being so busy delivering quality and features in Commerce Server 2006 as an excuse. But I won’t do that. Instead I will say that I’ve been accumulating a list of CS2006 topics and code samples to blog about.
While I’m posting, I want to point out that we have a new team member blogging about the great stuff coming in Commerce Server 2006. Alan Faulkner is a tester on the team who works on the CS2006 BizTalk adapters and is now taking on much of the Data Warehouse and Reporting test work. This guy’s really become an expert on the systems, so check him out. Plus he’s an east-coast transplant like me :-).
As we approach the dreaded “end game” of Commerce Server 2006, I’ve been reflecting on the release. Serving as a development manager is a new role from me. I’ve been with the Commerce Server team for quite a while – since Site Server Commerce Edition was in development, in fact. And what’s really refreshing is the increased focus on quality and excellence. I’m also incredibly lucky to work with an extraordinarily dedicated and talented team. This is truly the best Commerce Server team ever at Microsoft.
I hope that you’ll agree when you use the product. Our early feedback from the beta release of CS2006 has been resoundingly positive around this. We still have a little ways to go to put on all the finishing touches, fix the final wave of bugs, complete the documentation (it’s rather lacking in the Beta release – we’re working on it) and ultimately meet all of the release criteria. But I think you’ll agree that it’s already a big step up in terms of quality and consistency.
Let me know what topics you’d like to see more technical details around. Here are some of the blog ideas I’ve accumulated. Leave me feedback if you’d find particular value in any of these or have other areas you’d like to learn more about. Since I was formerly the developer for the discounting components in Commerce Server, many of these are marketing or discount related. I prefer to write about technologies and scenarios in CS2006 but if you have pressing issues with CS2002 I’m happy to address those as well.
- Qualifying discounts on custom properties of products that don’t come from the catalog system. This was a customer scenario where the requirement was to apply discounts to items that are recurring purchases. That can easily be achieved by adding a custom property to the line item (e.g. using the indexer) and then extending the Web service method that retrieves the “product” definitions so that the CS2006 Marketing Manager application (DiscountManager in CS2002 Feature Pack 1) will allow business users to include these properties in their discount expressions.
- How to implement promotion codes in the CS2002 Starter Site with Feature Pack 1 (this will be “out of the box” in the CS2006 starter site).
- About the new feature in CS2006 that allows advertisements and discounts to be targeted using Profiles other than UserObject and TargetingContext (a rather annoying limitation of the CS2002 targeting system).
- How to implement pipeline component property pages in .NET Winforms
- Expiring anonymous data (baskets, profiles, campaigns, etc)
- About COM Interop in Commerce Server
- Using codegen to build a strongly typed “Profile Object”
- Displaying the discounted price of a product the product listings page in a site. This turns out to be really hard to do in Commerce Server 2002. We’re making it much better in CS2006 but there are some limitations.
- Approaches to implementing bundling in Commerce Server 2006
- How do set up a complex shipping discount scenario: If the order exceeds $250 and a certain promotion code is entered, give free shipping for “standard” shipping method only.
- CS2006 and state/session management (a bit broad, much we could address around this)
- How to change the precedence of how OrderDiscount awards discounts to line items (on a per line-item basis instead of the global setting that’s already available).
by community-syndication | Mar 3, 2006 | BizTalk Community Blogs via Syndication
Ryan Donovan, the force behind MS Commerce Server, posts about the next version of Commerce Server, integration with Content Management Server (SharePoint), and the (non)-future of MSIB.
by community-syndication | Mar 3, 2006 | BizTalk Community Blogs via Syndication
Here is a list of the behaviors that I have found when using the custom pipeline component vs the adapter for receiving and sending data:
Pipeline
- Allows multiple recieve ’locations’ for a single party, where you define a receive location that has the configuration information and then multiple pick ups and drop offs, where they can be any adapter (file, ftp, http, MQ Series, etc.) can be used
- Ability to use Send Port Groups (archiving is an example of this usage)
- Does not check the interchange control number for duplication per party
- Data that is recieved or sent, is not archived in the location defined in the documentshome location in the parame table
- No information is logged to the audin and audout tables, so the HIPAA_EDI reports in HAT is not available
- Promoted properties in the WPC schemas are not invoked
Adapter
- Only a single port can be defined for receiving and sending
- Copies of both edi and xml data is stored in the documentshome location
- Interchange control number checking is done
- Information is stored in the audin and audout tables, so the HIPAA_EDI reports are accessable
- Using the DefaultXML pipelines; promoted properties can be used for correllation/filtering/orchestration usage
I have put together a really simple example of both usages, so differences can be seen.
Instructions:
- Deploy the Solution
- Using the Deployment wizard, import the Binding.xml file
- In the Management Console, in the HIPAA_EDI adapter, in the properties of the Send Handler, set the the Party to Us
- Restart the HIPAA service
- Enable the Receive Locations
- Start the Send Port
- Drop the file into the ..\input directory and see if the file is produced in the ..\output directory
- Notice the following information in HAT – HIPAA_EDI Reports
by community-syndication | Mar 1, 2006 | BizTalk Community Blogs via Syndication
A recent post in the BizTalk forum, promted this entry.
The question was asked how you can put the MessageID into a dynamic send port. I suggested that you would put a rule SendPort(Microsoft.XLANGs.BaseTypes.Address)=@”file://c:\”+DocumentMsg(BTS.MessageID)+”.xml”;
The next post was telling that you can put the macro in the Expression, which is true, you can, but in the below demo, it shows why it would be preferable not to use the macros.
I created a simple orchestration that shows both ways, here is the orchestration:
Here is the expression rule:
Here is the results of running the file through the orchestration:
In HAT, which is where I think that the real value of which method you use lies, here is the message flow, notice the filename is right in the first page of the message flow for the first outbound message, and the macro %MessageID% is found on the second message:
The message that uses the macro, you have to click on the link to see the actual message ID of what was saved.
Again, here is the output:
At a recent client site, I used the macro initially, but then moved to the BTS.MessageID to ease in troubleshooting. Saving a couple of clicks when attempting to find the file really adds up after a while.
by community-syndication | Mar 1, 2006 | BizTalk Community Blogs via Syndication
Recently I’ve been working with a system that involves an externally facing server acting as a Gateway for
another internal box, in this case a BizTalk Server. This system as such runs into
the glorious problem with .NET 1.1 limiting the maximum number of outbound HTTP connections
to 2 by default. This could impact performance but this far hasn’t been a problem.
This system has been working reasonably well for some time, but now there is a desire
to change the model of communication from one of submitted requests which receive
asynch responses to getting synch responses. This means connection lifetime will increase,
and as such the number of simultaneous connections had better rise with it or scalability
will go to hell. The place this needs to be changed is in the machine.config file
for .NET 1.1 and specifically you are looking for the maxconnection element, which
defaults to 2.
by community-syndication | Mar 1, 2006 | BizTalk Community Blogs via Syndication
In the last release of the BizTalk Deployment Framework, an additional feature was
added that I thought deserved its own post for explanation…
If you are responsible for troubleshooting BizTalk applications in production, you
are likely hungry for all the information you can get about why something is failing.
Since all BizTalk project assemblies are in the GAC, the stack traces you
get (either from your own logging, or the event logs BizTalk generates for unhandled
exceptions) do not contain file and line number information. This makes post-mortem
analysis a lot harder…
A new custom NAnt task (getgacpath) and corresponding support within BizTalkDeploymentInclude.nant
was added for placing PDB (program database) files for all BizTalk and component assemblies
into the GAC. (You can use just this NAnt task without the rest of the Deployment
Framework, of course. In addition, a standalone command line utility called
GetGacPath has been included in the “Tools” download.)
Why is this interesting? Well, because it allows you to get stack traces that
include file and line number information even when assemblies reside in the GAC.
(This is obviously useful and useable outside the domain of BizTalk…) Without
extra work, file and line number information is generally missing from a stack
trace if a PDB file is not co-located physically with the corresponding assembly.
Putting the PDB file directly into the GAC is an easy way of solving this problem.
Set the “deployPDBsToGac” NAnt property to “true” in your project-specific NAnt file
to get this functionality.
A couple of points are worth mentioning:
-
If the directory structure of the GAC were to ever change, this would need to be updated.
(See my upcoming post on using this technique with .NET 2.0.)
-
It would be great if Gacutil.exe provided this functionaity, but it doesn’t.
-
You should strongly consider having your release-mode binaries (aka ‘deployment’ configuration
in BizTalk) build PDB files – there is no reason not to. Look under Project
properties/Configuration properties/Build/Generate Debugging Information.
-
Stack traces that show up in the event log either through your own logging, or via
BizTalk (because the exception was unhandled) will now have file and line number info.
For orchestrations, the file name will correspond to the temporary C# file generated
at compile time. If you use the techniques described in this
post , you can correlate back to the actual statement that failed. For instance,
the event log might say:
[4740] ERROR BizTalkSample.Orchestrations.TopLevelOrch - An exception was caught.
[a08701ff-bf80-4940-9f9f-c2bb8597684b]
System.Exception: Something exceptional happened.
at BizTalkSample.Orchestrations.TopLevelOrch.segment2(StopConditions stopOn) in
c:\Documents and Settings\Scott\Local Settings\Temp\h0li3wbi.0.cs:line 2538
-
If you grab the file mentioned (h0li3wbi.0.cs) using BTSFileDump (again,see here)
you can cross-reference this message to a location in the generated C# code for TopLevelOrch:
You might save off “h0li3wbi.0.cs” (the temp file name chosen when TopLevelOrch compiled) and
the other generated files when you do your build, using BTSFileDump. (That would be
tough to do if you build with CruiseControl, etc.) But you wouldn’t have to
do that – if you can retrieve the source code used for a particular deployment,
then the line number alone should be sufficient to get you to the exception
site (since you can find the correct temp file by looking for comments, etc. that
are in the orchestration – just like if you were using this
technique to do live debugging.) This all gets better with BizTalk 2006
– see a future post on this topic.
-
Final point: If you set deployPDBsToGac to “true”, deployments will begin by stopping
the BizTalk services (instead of just bouncing the services at the end.) The
reason for this is that the BTSNTSvc.exe process will not “let go” of an assembly
for which it has loaded a PDB file (so you have to terminate it.) This means
you may not always want this switch on for the developer edit/run/debug cycle.
by community-syndication | Mar 1, 2006 | BizTalk Community Blogs via Syndication
In the last release of the BizTalk Deployment Framework, an additional feature was
added that I thought deserved its own post for explanation…
If you are responsible for troubleshooting BizTalk applications in production, you
are likely hungry for all the information you can get about why something is failing.
Since all BizTalk project assemblies are in the GAC, the stack traces you
get (either from your own logging, or the event logs BizTalk generates for unhandled
exceptions) do not contain file and line number information. This makes post-mortem
analysis a lot harder…
A new custom NAnt task (getgacpath) and corresponding support within BizTalkDeploymentInclude.nant
was added for placing PDB (program database) files for all BizTalk and component assemblies
into the GAC. (You can use just this NAnt task without the rest of the Deployment
Framework, of course. In addition, a standalone command line utility called
GetGacPath has been included in the “Tools” download.)
Why is this interesting? Well, because it allows you to get stack traces that
include file and line number information even when assemblies reside in the GAC.
(This is obviously useful and useable outside the domain of BizTalk…) Without
extra work, file and line number information is generally missing from a stack
trace if a PDB file is not co-located physically with the corresponding assembly.
Putting the PDB file directly into the GAC is an easy way of solving this problem.
Set the “deployPDBsToGac” NAnt property to “true” in your project-specific NAnt file
to get this functionality.
A couple of points are worth mentioning:
-
If the directory structure of the GAC were to ever change, this would need to be updated.
(See my upcoming post on using this technique with .NET 2.0.)
-
It would be great if Gacutil.exe provided this functionaity, but it doesn’t.
-
You should strongly consider having your release-mode binaries (aka ‘deployment’ configuration
in BizTalk) build PDB files – there is no reason not to. Look under Project
properties/Configuration properties/Build/Generate Debugging Information.
-
Stack traces that show up in the event log either through your own logging, or via
BizTalk (because the exception was unhandled) will now have file and line number info.
For orchestrations, the file name will correspond to the temporary C# file generated
at compile time. If you use the techniques described in this
post , you can correlate back to the actual statement that failed. For instance,
the event log might say:
[4740] ERROR BizTalkSample.Orchestrations.TopLevelOrch - An exception was caught.
[a08701ff-bf80-4940-9f9f-c2bb8597684b]
System.Exception: Something exceptional happened.
at BizTalkSample.Orchestrations.TopLevelOrch.segment2(StopConditions stopOn) in
c:\Documents and Settings\Scott\Local Settings\Temp\h0li3wbi.0.cs:line 2538
-
If you grab the file mentioned (h0li3wbi.0.cs) using BTSFileDump (again,see here)
you can cross-reference this message to a location in the generated C# code for TopLevelOrch:
You might save off “h0li3wbi.0.cs” (the temp file name chosen when TopLevelOrch compiled) and
the other generated files when you do your build, using BTSFileDump. (That would be
tough to do if you build with CruiseControl, etc.) But you wouldn’t have to
do that – if you can retrieve the source code used for a particular deployment,
then the line number alone should be sufficient to get you to the exception
site (since you can find the correct temp file by looking for comments, etc. that
are in the orchestration – just like if you were using this
technique to do live debugging.) This all gets better with BizTalk 2006
– see a future post on this topic.
-
Final point: If you set deployPDBsToGac to “true”, deployments will begin by stopping
the BizTalk services (instead of just bouncing the services at the end.) The
reason for this is that the BTSNTSvc.exe process will not “let go” of an assembly
for which it has loaded a PDB file (so you have to terminate it.) This means
you may not always want this switch on for the developer edit/run/debug cycle.
by community-syndication | Mar 1, 2006 | BizTalk Community Blogs via Syndication
There are some updates to the Deployment Framework and log4net story that I’ve been
meaning to release for quite some time. After this, I’ll focus my deployment efforts
on BizTalk 2006 (didn’t I say that last release?)
Below are a list of revisions. On this blog’s home page under “Downloads”,
you will find an updated full download (with sample), as well as updated
“Core” and “Tools” downloads. “Core” contains only the deployment framework
itself and can be used for upgrades of existing projects. “Tools” contains source
for all utilities used by the framework. Be sure to put a fresh copy
of BizTalk.NAnt.Tasks.dll in your nant\bin directory.
-
Update to the log4net.Ext.Serializable library. Note that the “Tools” download
now has variants of this library for both log4net 1.2.0 and 1.2.9, though the sample
is built against 1.2.9. The important change here is that the original version
of the library had a threading bug…as a result, the usage pattern for the library
has changed somewhat. Now, an instance of log4net.helpers.PropertiesCollectionEx
is declared (as an orchestration variable), and an expression shape at the top of
your orchestration will do something like below (notice logProps is passed to all logging
calls so as to preserve context despite thread changes across dehydrations.)
See the sample for additional detail.
logger = log4net.Ext.Serializable.SLogManager.
GetLogger(@"BizTalkSample",log4net.helpers.CallersTypeName.Name);
...
logProps.Set("InstanceId",TopLevelOrch(Microsoft.XLANGs.BaseTypes.InstanceId));
logger.Debug(logProps,"Received top level request...");
-
Update to the SSOSettingsFileReader class to include an “Update” method.
Likewise, an additional custom NAnt task called “updatessoconfigitem” that allows
you to add or update config items within an SSO affiliate application. What
is the use case for this? Suppose you have a piece of information that you a)
don’t want to store in SettingsFileGenerator.xls (perhaps because you can’t manage that
file securely) and b) you need access to at run time. (For instance, it
might be an Oracle username/password.) You could ask an operator/admin for this
information at deployment time using SetEnvUI.exe/InstallWizard.xml (from the
deployment framework) — and then in your project-specific NAnt file do this:
<target name="customSSO" if="${property::exists('serverDeploy') and serverDeploy}">
<updatessoconfigitem ssoitemname="databaseUserName" ssoitemvalue="${sys.env.databaseUserName}"/>
<updatessoconfigitem ssoitemname="databasePassword" ssoitemvalue="${sys.env.databasePassword}"/>
</target>
At runtime, you can simply use SSOSettingsFileReader to retrieve this information.
Note that this example checks for whether we are doing a server deployment – so in
this case, we would have the development environment values in SettingsFileGenerator.xls.
-
Added a small utility called SSONameValueDump to the tools download to view current
name/value pairs of an SSO affiliate application (if you have appropriate permissions.)
-
Update to the <controlbiztalkports> custom NAnt task to allow Send Port Groups
to be shared across projects. That is, Send Port Groups will only be removed
if they no longer contain Send Ports (and putting new Send Ports into an
already-existing Send Port Group will happen automatically.)
-
XmlPreprocess will be run against log4net configuration files, if you are using log4net.
This allows you to use SettingsFileGenerator.xls to control logging levels for different
physical environments.
-
SetEnvUI.exe no longer defaults to “last directory” when doing a file browse, to avoid
confusion between applications when managing multiple BizTalk application installs.
-
If you use ElementTunnel,
you will find that the xpath file will be reversed automatically for unescape operations
(thanks to Frank de Groot for that update!)
-
Fix: When deploying HTTP/SOAP infrastructure, file system permissions granted to the
specified application pool account.
-
Fix: The “quick update” target (updateOrchestrations) now respects true/false properties
for includeSchemas, includeTransforms, etc. (A menu option in Visual Studio is
created for this target when you use the MakeBizTalkExternalTools script. The target
updates orchestrations, components, schemas, and transforms (see Flanders’ post on
this) Using this as part of your normal edit/run/debug cycle is a must for
productivity…)
-
Fix: Handle multiple assemblies (of one artifact type) correctly in more cases, including
where we are not deploying to the management database (i.e. gac deployment only.)
Download: Full
Sample, Framework
Core, Tools
Source
by community-syndication | Mar 1, 2006 | BizTalk Community Blogs via Syndication
There are some updates to the Deployment Framework and log4net story that I’ve been
meaning to release for quite some time. After this, I’ll focus my deployment efforts
on BizTalk 2006 (didn’t I say that last release?)
Below are a list of revisions. On this blog’s home page under “Downloads”,
you will find an updated full download (with sample), as well as updated
“Core” and “Tools” downloads. “Core” contains only the deployment framework
itself and can be used for upgrades of existing projects. “Tools” contains source
for all utilities used by the framework. Be sure to put a fresh copy
of BizTalk.NAnt.Tasks.dll in your nant\bin directory.
-
Update to the log4net.Ext.Serializable library. Note that the “Tools” download
now has variants of this library for both log4net 1.2.0 and 1.2.9, though the sample
is built against 1.2.9. The important change here is that the original version
of the library had a threading bug…as a result, the usage pattern for the library
has changed somewhat. Now, an instance of log4net.helpers.PropertiesCollectionEx
is declared (as an orchestration variable), and an expression shape at the top of
your orchestration will do something like below (notice logProps is passed to all logging
calls so as to preserve context despite thread changes across dehydrations.)
See the sample for additional detail.
logger = log4net.Ext.Serializable.SLogManager.
GetLogger(@"BizTalkSample",log4net.helpers.CallersTypeName.Name);
...
logProps.Set("InstanceId",TopLevelOrch(Microsoft.XLANGs.BaseTypes.InstanceId));
logger.Debug(logProps,"Received top level request...");
-
Update to the SSOSettingsFileReader class to include an “Update” method.
Likewise, an additional custom NAnt task called “updatessoconfigitem” that allows
you to add or update config items within an SSO affiliate application. What
is the use case for this? Suppose you have a piece of information that you a)
don’t want to store in SettingsFileGenerator.xls (perhaps because you can’t manage that
file securely) and b) you need access to at run time. (For instance, it
might be an Oracle username/password.) You could ask an operator/admin for this
information at deployment time using SetEnvUI.exe/InstallWizard.xml (from the
deployment framework) — and then in your project-specific NAnt file do this:
<target name="customSSO" if="${property::exists('serverDeploy') and serverDeploy}">
<updatessoconfigitem ssoitemname="databaseUserName" ssoitemvalue="${sys.env.databaseUserName}"/>
<updatessoconfigitem ssoitemname="databasePassword" ssoitemvalue="${sys.env.databasePassword}"/>
</target>
At runtime, you can simply use SSOSettingsFileReader to retrieve this information.
Note that this example checks for whether we are doing a server deployment – so in
this case, we would have the development environment values in SettingsFileGenerator.xls.
-
Added a small utility called SSONameValueDump to the tools download to view current
name/value pairs of an SSO affiliate application (if you have appropriate permissions.)
-
Update to the <controlbiztalkports> custom NAnt task to allow Send Port Groups
to be shared across projects. That is, Send Port Groups will only be removed
if they no longer contain Send Ports (and putting new Send Ports into an
already-existing Send Port Group will happen automatically.)
-
XmlPreprocess will be run against log4net configuration files, if you are using log4net.
This allows you to use SettingsFileGenerator.xls to control logging levels for different
physical environments.
-
SetEnvUI.exe no longer defaults to “last directory” when doing a file browse, to avoid
confusion between applications when managing multiple BizTalk application installs.
-
If you use ElementTunnel,
you will find that the xpath file will be reversed automatically for unescape operations
(thanks to Frank de Groot for that update!)
-
Fix: When deploying HTTP/SOAP infrastructure, file system permissions granted to the
specified application pool account.
-
Fix: The “quick update” target (updateOrchestrations) now respects true/false properties
for includeSchemas, includeTransforms, etc. (A menu option in Visual Studio is
created for this target when you use the MakeBizTalkExternalTools script. The target
updates orchestrations, components, schemas, and transforms (see Flanders’ post on
this) Using this as part of your normal edit/run/debug cycle is a must for
productivity…)
-
Fix: Handle multiple assemblies (of one artifact type) correctly in more cases, including
where we are not deploying to the management database (i.e. gac deployment only.)
Download: Full
Sample, Framework
Core, Tools
Source
