All full up, eaten several families out of house and home and we all slept under the tree waiting for Santa...early mornings.....:| Best wishes and see you all in 2007 for an even better year!
I'm thinking this is a bad thing if you want dynamic resolution. I've experienced this with both the XMLReceive and a Custom Flat File Receive Pipeline (I built). 1. Both worked a treat - '5 minutes ago' as I've been working away. 2. Went into the BizTalk Admin console and 'adjusted' a property on the pipeline at the receive location ->clicked on the '...' button next to the pipeline. 3. Even if you dont change anything and hit OK...you're affected. 4. XMLReceive + FlatFile both complain about ' blank document schema' which must be specified.
(as in this case I'd changed a few things coding....it took me AGES to come back to here)
I even explicitly supplied the correct schema as a property on the FFDASM component I was using and no go!
5. Resolution: go back to the pipeline within the receive location (or send port) and select another pipeline from the list. Click OK to close the property window, then repeat and add your original pipeline but dont go into the pipeline per instance properties pages
Why does this happen??? (yeah good question :)
Basically both the XMLDASM and the FFDASM take precedence with Per instance pipeline config properties than *anything* else you provide.
e.g. Dynamically processing a flat file - check the SDK example, but here's a pseduo version.
.....
//Flatfile schema resolver - normal technique.
DocumentSchema docSpec = ......determine which deployed schema to use.
//this line basically tells the Disassemblers which schema to apply.
msg.Context.write("DocumentSpecName","<system namespace xml-norm>",docSpec.DocSpecStrongName);
_myFFDasm.Disassemble(msg); // line - *
These above lines will work for a year and a day (I've tested this) and in both 2004 + 2006, but NOT when you add perinstance pipeline configs - it seems all 'dynamic-ness' has gone out the window.
When per instance pipeline config is specified, this config data is provided as a Message Context Property (ReceivePipelineConfig) and XMLDasm + FFDasm only look at this for their values - painful.
So as in my case, I hadnt specified a Document Schema within the pipeline config as this pipeline was dynamic (c.f. like the xmlReceive).
I explicitly assigned a Schema to the FFDasm.DocumentSchema property and still got the same error as before.
Removing the Config Data did the trick :)
Given that this is the case - I think when you hit 'OK' to save the pipeline config data a warning/message of some description should come up as you may be wanting to modify 'one' value - 'omit xml declaration' for example. The rest of the properties are written in as blanks.
Hopefully I've saved you a bit of pain from mine.
Making some headway with this issue I'm experiencing.
I can now go into the BizTalk Application and configure most of the resources found within the Application. I've ventured into Microsoft.BizTalk.ApplicationDeployment.Engine.dll (found in the GAC) and was able to enumerate all the resources etc.
The only thing I havent been able to do is 'an update' to the resource properties (metadata).
I can re-add the resource and overwrite the existing ones, this time with the correct settings, but the problem here is that resources that have dependenies fail. e.g. schemas, maps....
For better of for worse right now I've located the two tables in the BizTalkMgmtDB and modified those directly - all looks good.
The interesting thing is I used %BTAD_InstallDir% extensively throughout the DestinationLocation.
Setting that at deploy time use:
msiexec /i <package.msi> /quiet /log <logfile> TARGETDIR=<your location>
Somewhere within the MSI Installer component within the Package - TARGETDIR=%BTAD_InstallDir%
(Even though all the documentation talks about %BTAD_InstallDir% being an environment variable)
I was coming across some issues with my WCF Service Clients and not shutting down properly. They were throwing exceptions for various reasons and while trawling the ether I came across a great helper class (and this is where I saw the c# where clause) from Erwyn van der MeerThe problem centers around calling proxy.Abort(); or proxy.Close(); at different stages in the client proxies lifecycle. Microsoft explain why we have arrived where we have on this - great candid discussion from the internal crew. He discusses the problem and provides a great WCF client proxy helper class. Here's a snippet from the Microsoft Discussion Why does ClientBase Dispose need to throw on faulted state? (Or, what's the difference between close and abort?)ICommunicationObject
(from which ServiceHost, ClientBase, IChannel, IChannelFactory, and
IChannelListener ultimately derive) has always had two methods for
shutting down the object: (a) Close, and (b) Abort. The semantics are
that if you want to shutdown gracefully, call Close otherwise to
shutdown ungracefully you call Abort.
As a consequence, Close()
takes a Timeout and has an async version (since it can block), and also
Close() can throw Exceptions. Documented Exceptions out of Close are
CommunicationException (of which CommunicationObjectFaultedException is
a subclass), and TimeoutException.
Abort()
conversely is not supposed to block (or throw any expected exceptions),
and therefore doesn’t have a timeout or an async version.
These two concepts have held from the inception of Indigo through today. So far, so good.
In
its original incarnation, ICommunicationObject : IDisposable. As a
marker interface, we thought it would be useful to notify users that
the should eagerly release this object if possible. This is where the
problems begin.
Until
Beta 1, we had Dispose() == Abort(). Part of the reasoning was that
Dispose() should do the minimum necessary to clean up. This was
possibly our #1 complaint in Beta 1. Users would put their channel in a
using() block, and any cached messages waiting to be flushed would get
dropped on the floor. Transactions wouldn’t get committed, sessions
would get ACKed, etc.
Because
of this feedback, in Beta 2 we changed our behavior to have Dispose()
~= Close(). We knew that throwing causes issues (some of which are
noted on this thread), so we made Dispose try to be “smart”. That is,
if we were not in the Opened state, we would under the covers call
Abort(). This has its own set of issues, the topmost being that you
can’t reason about the system from a reliability perspective. Dispose
can still throw, but it won’t _always_ notify you that something
went wrong. Ultimately we made the decision that we needed to remove
IDisposable from ICommunicationObject. After much debate,
IDisposable was left on ServiceHost and ClientBase, the theory being
that for many users, it’s ok if Dispose throws, they still prefer the
convenience of using(), and the marker that it should be eagerly
cleaned up. You can argue (and some of us did) that we should have
removed it from those two classes as well, but for good or for ill we
have landed where we have. It’s an area where you will never get full
agreement, so we need to espouse best practices in our SDK samples,
which is the try{Close}/catch{Abort} paradigm.
Brian McNamara [MSFT]
Came across some interesting code the other day and I must admit I hadn't seen the Where clause used like this before: using System;
class MyClassy<T, U>
where T : class
where U : struct
{
} And according to the Microsoft Definition found herewhere (C# Reference)
The where
clause is used to specify constraints on the types that can be used as
arguments for a type parameter defined in a generic declaration. For
example, you can declare a generic class, MyGenericClass, such that the type parameter T implements the IComparable<T> interface: public class MyGenericClass<T> where T:IComparable { }
Usually when referencing an external website we use http://...... and we lose all the security etc. information that comes back from our crawls. (In contrast to the File://c:/docs/... etc etc)
A handy tip you can do is IF you know the site is a sharepoint site you can use the SPS moniker so the indexing service uses the Sharepoint APIs to contact the site as opposed to the http:// protocol handler.
(1) for SPS v2 use SPS://.....
(2) for SPS v3 use SPS3://....
Enjoy.
When I was onsite recently doing a sharepoint migration to MOSS 2007 from WSS V3 - for whatever reason all the servers (and databases) were blown away and all the client had was one content database of their site.
(Who said client sites werent exciting)
My solution here:
(1) install and configure the farm independent of the original content database
(2) Setup the the Shared Services for the Farm
(3) Extend 1 virtual server and create a new content database.
Here's the trick....
(4) From 'Application Management'->'Content Databases'....add another ContentDB
(5) Now select the original ContentDB as an additional one to add. At this point when you click 'OK' there should be two in the list
(I had to actually drop to the command line as this content database addition was going to take more time than the webinterface allowed.
stsadm -o addcontentdb -databasefile:..... -databaserver:..... -url:......)
(6) From the list of two Content Databases - take the non-original ContentDB offline and then remove it.
Viola! Worked a treak...I had to sort out a couple of things around links etc.
(I did try a few other techniques first and got a whole bunch of errors around 'object not in the correct state')
Cheers,
Mick.
On the whole - BTSTask.exe is a great improvement over BTSDeploy.exe in 2004.
A couple of things I wouldnt mind seeing in this tool - the ability to start/stop deployed applications.
Big Gotcha
Something I came across after my large scripting effort.....it goes something like this....
(1) 3 biztalk applications - a 'Core' and Two others.
(2) For the 'Core' apart from Schemas, Maps, Pipelines + Orchestrations; I had 1 COM Assembly, 2 custom adapters, 4 custom functoids and 3 custom pipeline components
So a reasonable sized deployment that needed to easily be deployed into test/production.
My line of thinking was - "If I could get all the associated *.dlls deployed into the BTS Core Application wthin Development...all would be good."
So as we know we can go through the BTS Admin Console and add resources/files/bindings etc. to our application (with various options), that way when we say "Export to MSI..." it's self contained.
The PROBLEM is in the 'Destination Location'....
Using the BTSTask AddResource..... setting the '-Destination:' parameter works a treat (IF your destination location exists within development environment!)
Let me ellaborate....
Development:
e:\projects\<project name>\BizTalk\
- maps
- schemas etc....
Associated *.dlls - found e:\projects\<project name>\CommonBin\Release
Testing/Production:
d:\Applications\<project name>\CommonBin...etc. etc.
So the drives are different and what's more, there is NO d-drive in Development....hmmm....I thought.
(I didnt have a 'demo' project to highlight this....so I've removed company info from below)
Where I want to focus is the 'Destination Location'
These 4 assemblies are deployed using VS.NET 2005 straight from the developers desktop.
(When using BTSTask AddResource....-Destination:<loc> - loc has to exist at time of adding and 'exporting MSI' - bts validates)
Export to MSI...fine MSI finally created.
Installing the MSI file in Production/Testing
Upon performing MSIEXEC /quiet /i Core.MSI FOLDER=d:\Applications\<Project Name>\CommonBin\
I ended up getting a 'msi package deployment' - a guid as a foldername with *.CAB files underneath. No *.dlls etc to be seen.
Importing Into BizTalk
Went to BTS Admin Console and did ImportApp - all looked good.
Then went to the D-Drive and found no new files?? where were my biztalk files? gac-ed files etc?
The ones that needed Gac-ing - found copied to the GAC
The BizTalk ones Schemas, Maps etc - found in E:\projects\<project name>\<development project path>\Bin\Deployment\.....smooth! :-(
As far as I can tell this is attributed to the already existing 'destination location' within the MSI on the BizTalk artifacts.
So the reason why it's soooooo close is that if we could override this (i.e. the above FOLDER= parameter takes effect) then all would be sweet in going from environment to environment.
As it stands at the moment, I'm deploying all the files to Testing building the MSIs there and then deploying to Production with all the correct paths hopefully.
Thought I'd save you some tears.
Buried deep down in one of the Install Guides (multiserver, pg 23) I came across a section that shows you where to change the BAM alert email formats.
Basically there are two files - emailNotification.xslt and fileNotification.xslt both found in the ...\Microsoft BizTalk Server 2006\Tracking directory.
If you want to split the function of BAM alerting to different machines (the Provider, Generator and Distributor within the Notification Services) then there's a little step you need to do, to tell the BAM Alerting Event Provider where these new XSLT files are.
Within the Tracking Dir:
1. Run ProcessBAMNsFiles.vbs - this creates a *.adf file.
2. Edit the *.adf file to point to the new names/location of your modified *.xslt files.
3. ReRun ProcessBAMNsFiles.vbs so it picks up the modified *.adf file and makes the changes to the BizTalk Runtime.
4. Restart the BAMAlerts Windows Service.
Handy one - especially being able to modify those emails.
From students one of my most asked questions about MOSS is...."Will it handle an upgrade?"...something along the lines of .."...you know we have a medium installation of 183 distributed V2 sites with central portals, index propagation and search."
So I thought I'd outline some of my initial upgrade experiences from MOSS RTM.
(On this install - used by a small-medium sized company, they were up for technology so we had SPS2003+SP2...->MOSS Beta2 installed for a while. The RTM install wouldnt kick off until I removed Beta2)
After the product key in the setup I got these upgrade screens....(once the product is installed we can always run the psconfig.exe to start the 'wizard')
I'm doing all at once here - as this company is pretty standard in that fashion. Customisation here weigh in at about 10% of the overall Sharepoint site functionality.
Here's the screen for the File Locations - I moved these out to D-Drive (separate disk) and all the Indexing will be hit pretty hard.
Rule of thumb is to allow 200% space increase for the indexed content. So if you're indexing 100MB, then 200MB free for indexing is recommended.
Actually the search/index process in MOSS is pretty well defined and taking its roots from 'Indexing Service' many many moons ago. The indexes (known as Catalogs - you can access these through the APIs etc) are stored in a highly optimised format. Compressed! And the process of 'indexing' content can be 'tweaked' through things like 'the number of Word lists' in memory, Shadow Indexing and finally the master Index.
Some one was smiling....:)
So at this point I have all the binaries installed and all the appropriate files registered.
The Wizard will go and (hopefully) create the first Admin Site, which from there I can provision the actual Content based sites and the Shared Services (search, excel, mysite etc)
(damn...got hit with a 'we need to reboot to continue...' - so rebooting now.)
Just came across this great info I thought I'd share with you all.
If you're like me over Christmas you'd be giving some thought on how to make the most out of your newly slated WSS/MOSS 2007 Server.
Hold onto your hats - stop all custom development and give your graphic designers a buzz.......
Here's something to keep an eye on in the coming weeks!! Over 40 new templates......
http://www.microsoft.com/technet/windowsserver/sharepoint/wssapps/v3templates.mspx
Here's a snippet from the page.....(expense site, bug tracking....:)
Coming Soon: New Application Templates for Windows SharePoint Services 3.0
 |
Application Templates are out-of-box custom scenarios for the Windows SharePoint Services platform, tailored to address the needs and requirements of specific business processes or sets of tasks in organizations of any size.
Microsoft will release a new set of 40 application templates for Windows SharePoint Services 3.0. Some of the previous scenarios, such as Help Desk, Project Site, Knowledge Base and the Employee/HR templates will be improved to incorporate and highlight new capabilities in Windows SharePoint Services 3.0. New scenarios will also be added to address specific customer needs and business requirements.
While Application Templates can be used to solve particular business needs, they can also provide a starting point for partners and developers looking to build deeper Windows SharePoint Services solutions. The new templates will make use of Windows SharePoint Services 3.0 capabilities and be compatible with Office SharePoint Designer 2007 to help make customization easier. |
| 40 New Application Templates* |
Forty new Application Templates are coming soon for Windows SharePoint Services 3.0. Twenty of the templates will be “site admin templates” and available in English only. These templates will be easy for site administrators to install in a template gallery without requiring server administration access.
The remaining twenty will be “server admin templates” and available in eleven languages (English, French, Italian, German, Spanish, Portuguese, Japanese, Chinese Simplified, Chinese Traditional, Korean, and Hebrew). These will be created as site definitions, providing tighter integration and enhanced functionality within the Windows SharePoint Services platform. They will require a server administrator to install.
*List of Application Templates for Windows SharePoint Services 3.0 subject to change.
Upgrades: Microsoft will release tools and guidance to help customers upgrade from some of the previous Application Templates for Windows SharePoint Services 2.0 to run on the new Version 3.0 platform. Application Templates for Windows SharePoint Services 3.0 are not backwards-compatible with Version 2.0. |
Multi-Language Server Admin Templates
 |
Absence Request and Vacation Schedule Management |
|
Budgeting and Tracking Multiple Projects |
|
Bug Database |
|
Call Center |
|
Change Request Management |
|
Compliance Process Support Site |
|
Contacts Management |
|
Document Library and Review |
|
Event Planning |
|
Expense Reimbursement and Approval Site |
|
Help Desk |
|
Inventory Tracking |
|
IT Team Workspace |
|
Job Requisition and Interview Management |
|
Knowledge Base |
|
Lending Library |
|
Physical Asset Tracking and Management |
|
Project Tracking Workspace |
|
Room and Equipment Reservations |
|
Sales Lead Pipeline | |
English Only Site Admin Templates
|
Board of Directors |
|
Classroom Management |
|
Clinical Trial Initiation and Management |
|
Competitive Differentiation Site |
|
Discussion Database |
|
Emergency Management for Government Agencies |
|
Employee Activities Site |
|
Employee Self-Service Benefits |
|
Employee Training Scheduling and Materials |
|
Equity Research |
|
Manufacturing Process Management |
|
Marketing Campaign Planning and Execution |
|
New Product Development |
|
New Store Opening |
|
Product Portfolio and Profitability Management |
|
Request for Proposal |
|
Sports League |
|
Team Work Site |
|
Timecard Management |
|
Vendor Performance Rating | |
(This is courtesy of Ross a collegue of where I'm working onsite currently)
What you need is:
(1) a Send Port with the MSMQ Send Adapter
(2) XMLTransmit pipeline
Within the MSMQ Send Port adapter - set the Body Type to a value of 30 (this translates back to the Win32 API values and you can look them up for the enumeration, so it's not a value of 8=BSTR a trap which we may fall into)
Within the XMLTransmit pipeline - click on the ellipse to set per instance configuration settings for this pipeline.
Set 'Include XML Declaration' =false
Set 'Preserve BOM...' = false (byte order mark - the 3 chars that are a bomb, upside-down question mark etc) so the client wont receive it.
Once this is done - all good!
Your clients who expect just ActiveX formatted messages only, are happy to play with BizTalk.
Thanks Ross!
From an earlier email today.....
  
MS Partners Save 25-30% on Certification Exams
December 5, 2006
In concert with Microsoft’s Partner Skills Plus program, Microsoft Certified Partners, Gold Certified Partners, and Registered Members can save 25-30% on Microsoft certification exams – currently available only at Pearson VUE® Authorized Test Centers. These certifications are focused on the latest Microsoft products and technologies and align to Microsoft Partner Program competencies. Significant savings are also available on practice tests from MeasureUp. This is a limited time offer; visit https://partner.microsoft.com/examsavings to request your vouchers now.
Not currently a Microsoft Partner Program Member? Becoming a member of the Microsoft Partner Program can open new windows of opportunity for you and your organization. To enroll in the program or to associate your email address with a partner company, visit https://partner.microsoft.com/examsavings and click on ?Program Membership.? There is no cost to enroll as a Registered Member; join now and start saving on exams today.
|
|
Copyright © 2008 Breeze Training. All rights reserved.
|
|