When starting a BizTalk project I generally follow the naming conventions found here. Where you name your projects and assembly's something like:
MyCompany.MyProject.Orchestrations.dll
MyCompany.MyProject.Schemas.dll
MyCompany.MyProject.Pipelines.dll
MyCompany.MyProject.Transforms.dll
MyCompany.MyProject.PipelineComponents.dll
A couple of questions for other BizTalk folks:
1) I usually find myself having more than one project with schemas or a need to separate schemas. Do you stick them in separate assemblies and if yes, what convention do you then follow for naming the project/assembly. If no, do you stick them in a subfolder in one assembly.
2) I believe, could be wrong, that it's been sort of a BizTalk convention to name the project and assembly the same, like above. I've thought about getting away from naming the projects the same as the full assembly name, so I might have the project named Maps and it's assembly is named MyCompany.MyProject.Maps. Do others do this?
Starting with BTS 2009 we named our projects and assemblies according to the application they belong to plus an optional sub-application or concern scope:
MyCompany.Biz.MyFirstApp.dll
MyCompany.Biz.MyFirstApp.Util.dll
MyCompany.Biz.MyFirstApp.ConcernOne.dll
MyCompany.Biz.MySecondApp.dll
We took the path to keep orchestrations, schemas and maps together because multi-assembly dependencies can make deployment a real hassle.
Our main goal was to separate source and target systems to avoid direkt references. We achieved this be introducing "core" components for all concerns we're dealing with:
BTS application MyFirstApp
MyCompany.Biz.MyFirstApp.OrderProcessing.dll
MyCompany.Biz.MyFirstApp.Util.dll
BTS application CORE
MyCompany.Biz.CORE.OrderProcessing.dll
BTS application MySecondApp
MyCompany.Biz.MySecondApp.OrderProcessing.dll
Both MyFirstApp and MySecondApp will reference schemas in CORE.OrderProcessing.
Update
MyCompany.Biz.MyFirstApp.OrderProcessing would contain the message schema for incoming order documents and a map for mapping those into the core order message schema (contained in MyCompany.Biz.CORE.OrderProcessing). If needed it could also contain an orchestration for receiving messages and (receive) pipeline components (when dealing with flat files for example).
MyCompany.Biz.MySecondApp.OrderProcessing would contain the message schema for outgoing documents and a map for mapping from the core order message schema (to outgoing).
In this basic layout CORE will merely be a container for your internal message schemas but it will be the best location to add information to your order documents - for example an orchestration which awards a global discount for class A customers (Business Rules!). In short basically any step you'd do twice or even more times when sending or receiving messages and you do not want to touch if incoming or outgoing message schemas changes or new application is added.
Here is a wonderful BizTalk Naming Conventions guide from Scott Colestock
Related
We are updating a BizTalk 2009 application that I inherited. I'm converting them into BizTalk 2013 R2.
I get the following reasonably famous error, when I try to re-compile
Exception Caught: Cannot load source/destination schema: MyCompany.Schema.AppConfig.
Either the file/type does not exist, or if a project dependency exists, the dependent project is not built.
There are only two posts in SOF related to this error:
Biztalk Map Destination Schema Imports Multiple Schemas
Reference trouble with BizTalk schema project in Visual Studio 2008
and only a few meaningful posts in elsewhere.
The solution has 4 projects organized as follows:
Common (contains an 1 schema AppConfig.xsd file)
Orchestration (1 Orchestration file)
Schema (references an ASMX web service)
Map (1 map file, references Schema and Common Projects)
The Map project attempts to translate an source message of type AppConfig to the type AppConfigBE which is one of the Complex Types in the Web Service.
I keep getting the compile time error above.
Tried all of the following, as recommended in the two SOF posts, and a few other posts on MSDN forums, but none of it worked.
Tried alternating Copy Local on the Maps project (From true to false, and vice-versa)
Tried Replacing schema on source and destination on the map file
Schemas are referenced using fully qualified .Net type name
Tried referencing the .dll as opposed to the Schema and Common projects.
Updated the web reference; also removed and re-added the web references
Is there a solution/hot fix etc for this? Any other suggestions I can try?
UPDATE 1:
We had to call Microsoft for help; the engineer took my project file to try on their computers; he said they too had the same problem and as a fix, recommended to set the Build Action property of the .BTM map file to None instead of BTSCompile. After this, the project builds successfully. He said to test the project with this build and let them know. What I'm not sure is, what are consequences of this? Many topics on Build Action refers to the schema files, not the map files in a BTS project. What is the standard Build Action for Map files?
One more item is to clear any Assemblies from the GAC or re-GAC them with a Post-Build script.
I ran into the same problem. I needed to add
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.XLANGs.BTXEngine;
[assembly: Microsoft.XLANGs.BaseTypes.BizTalkAssemblyAttribute(typeof(BTXService))]
to the AssemblyInfo.cs into the project.
If I want to call a web service or wcf method from an orchestration, I can do it by either adding a service reference to the project or adding a generated item. What is the advantage of either approach - is there a best practice?
Steef -Jan Wiggers answers a similar question here
TL;DR - Always use the Generated Items wizard.
My 10c - Although the .xsd files imported by Add Service is added as a schema and set to BtsCompile, there are some limitations such as:
Add Service Reference will add the client proxy, which isn't needed in a BizTalk project (and which might 'tempt' your devs to do silly things like using this proxy from a Custom assembly)
Service Reference makes a mess of importing complicated WSDL (e.g. with Generics or dependencies on other Schemas), See Considerations when consuming Web Services
Using the Add Generated Items wizard does extra work for you:
Adds in a Port Type for accessing the service, already preconfigured for the correct message types. Note however that it adds the Port type to a dummy .odx - i.e. don't delete the odx until you've moved the Port type elsewhere.
Allow you to create the Send Port bindings at the same time.
One thing I would recommend with the Wizard, is to create a folder for the WCF reference and always import all the artifacts into the folder (i.e. don't do the usual separation of Schemas from Ports and leave the dummy .odx there as well). This way, if you need to regenerate the items, just delete everything in the folder and start again (sadly, the wizard doesn't have a Update Service Reference equivalent.
Also note that if you do move the generated Schemas and Port Types into a separate assembly, that you will need to change the type modifier access to Public (it is internal by default)
Hi i want to know what is meant by modules in a project??how they are classified and how many modules we can have in a project?can anyone explain with simple examples??What modules we can have in a typical online shopping website?
In .net context I believe one can draw 2 meanings not sure what specific you are looking for.
One is modular programming by following design principles like "Separation of concerns", "Single Responsibility", "loose coupling". This means divide you code into classes based on these principles and further group these classes again based on these principles into modules.
In ASP.NET or C# or in general we create class library projects and use them across the entire project. Like all the logging functionality is put in some classes and these classes are include in an class library project which can be called "Logging module". Whenever you need logging in any of the project you can include this module and use the functionality.
Some examples:
Web module for HTTP requests ( The WebApp)
Repository and Data access Layer modules. (DAL code)
Models module containing all the business entities.
WebService modules for integrating with other apps.
Logging for debugging and problem identification
Infrastructure/Utility modules for utility like functionalities and
application configuration.
Business logic modules.
Transaction gateway module.
Other way to define module in .net is they are PE files and I believe they have extension .netmodule which contain Metadata but they do not contain the assembly manifest. To use a module you have to create a PE file with the necessary assembly manifest.
Create a module:
csc /t:module ufo.cs
Create assembly using the module:
csc /t:library /addmodule:ufo.netmodule /out:airvehicles.dll helicopter.cs
Above 2 commands are from this link
The module is an external code that you plugin on your site and runs in order to do some actions.
(source: codeguru.com)
We make and use modules to have the ability to share the actions of the module with others with out giving the source code, and vice versa, we use modules from other that we do not have access to the source code. Or we can simple use module for have the ability so simplify our code and remove it easy if we do not need it.
We can have as modules as we like, but each module place extra overhead on our code - after all is need to make more thinks there.
More about modules: http://www.codeguru.com/csharp/.net/net_asp/article.php/c19389/HTTP-Handlers-and-HTTP-Modules-in-ASPNET.htm
How to create module: http://support.microsoft.com/kb/307996
I've got stuck with a problem. I've an BizTalk 2010 application which references a Third party Schema dll. Our Architect told us not to directly reference it as it'll take more time to serialize this huge around 9MB dll which will cause Biztalk work more.
Since this Third part dll is a schema dll it'll be deployed to MgmtDb under any of the applications prior any other app deployment. Our orchestration messages has messagetypes which are referenced from this schema dll.
What I want to know is where excatly this serialization of this external dll taking place as the this dll already been deployed and Orchestration instance can reference this against any request messages which comes in.
Do serialization happen for each message which creates an orchestration instance.
Please share your thoughts.
Thanks.
While its true that the referenced assembly will be added into MgmtDB, AFAIK it is only metadata about the assembly and the artifacts in it which is added, e.g.
use BizTalkMgmtDb
select * from dbo.bts_assembly
... dbo.bts_orchestration
... dbo.bt_DocumentSpec
etc.
Possibly he/she is refering to instances of messages created from schema classes in the assembly (and are stored in the messagebox). But the size of the messages will be determined by the size of the data in it, not by the size of the assembly.
Since you seem to need the referenced message schemas, there isn't much option but to reference it in your new project (e.g. unless you have the source to the 3rd party assembly where you could refactor it and split it into several smaller assemblies). The 3rd party assembly needs to be deployed on your BizTalk servers and signed and GACed.
However if this referenced schema assembly also contains other artifacts like custom classes used in orchestrations as variables, these classes will also need to be serializable as soon as the orchestration hits a dehydration point (to avoid this you would need to scope the variables out before the dehydration and / or use an atomic scope to prevent BizTalk from dehydrating at all, but this is generally a bad idea as it will limit scalability)
Your Architect has made an incorrect assumption about when BizTalk performs validation of a Document against its defined Schema.
Validating a large Document against a hefty Schema, such as an EDIFACT or OASIS, can take a lot of resources. BizTalk therefore will not validate an incoming Document against its relevant schema unless you explicitly ask it to do so in the Receive Pipeline. By default, most Pipeline components will have their 'ValidateDocument' property set to 'False'. BizTalk will therefore only perform Document recognition, based on the namespace and root node, and this is done while stream-reading the first couple of hundred bytes of the document stream.
So, you can freely 'reference' the third party DLL, the only performance penalty will be at compile and deployment time. If, for some reason, you need to validate a Document against this Schema, you would need to have it in the Management DB regardless.
I am a total newbie on Prism. I have been getting to understand a lot from questions on SO and from various Blogs. I am using latest build – V2
I want some explanations on things that may be pretty easy things for you guys but it’s just not getting into my brains (small one for that).
Instead of doing it all right the first time , for which I have spent more than two weeks looking at various blogs, webcast …., I thought to start a project and learn. The amount of information on those hundreds of sites was overwhelming and difficult to digest.
Currently my project is setup like this
Shell -- Menu Module- ViewModel - - -> Menu Service -- -- > Menu Repository --- Data
All are in different assembly
MyShell --- MenuModule ---MyServices -- Myrepository
Shell is required to reference modules ( thought I am sure I can add it using string) later on .
ViewModel has a reference to View - Can live with it for now
View Model requires to use menu service and menu service uses repository
All are built with constructor injection. I have it working now by having module reference MyService and Myrepository projects and then registering types at module level.
But this does not feel good. I don’t want to hard reference any projects. If we are referencing projects why use IoC. In MenuModule.cs ( which is in the root of module) I can register views with unity container
I think I am getting a feel that the answer to this one may lie in the first question
Is Configuration file the answer/
Should I use configuration file for
true decoupling?
If (somehow) we can
register types from code, should we
register types at module level ( I
don’t want to have hard reference to projects)
I need to know the
Interfaces in advance so do you
recommend separate assembly for just
Interfaces?
Bear with me if the questions sound real stupid
You don't need a configuration file for true decoupling. All you need is to register your types in your shell's bootstrapper. I usually break up my projects and refs like this.
Contract Assembly
(Contains only a few simple types and interfaces)
Referenced by:
Shell
Modules
Shell
(Contains concrete implementations of interfaces defined in Contract assembly)
Referenced by:
No one
Modules
(Declares dependencies on interfaces defined in Contracts assembly, for instance IMenuRegistry)
Referenced by:
No one (I use a Directory Module to search for modules in a directory)
Here's a sample project I put together. In this sample I reference the module from the shell for simplicity's sake, but you can remove that reference and use a directory module catalog to load the compiled module at runtime:
http://dl.getdropbox.com/u/376992/CAGMenus.zip
Hope this helps,
Anderson
You're definitely on the right track. Use the configuration file to register your types, and put the interfaces in a separate assembly.