Sunday, May 04, 2008

We are taking off for a new adventure in development:
It's about developing a framework which will enable us to persist our business objects into databases, file systems or xml file system.


STEP 1: CREATING A BUSINESSOBJECT ATTRIBUTE

namespace
ORMCore
{
///
/// This attribute is used to enable the ORMFramework
/// to create an associate table on the RDBMS
///

[
AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
public class BusinessObjectAttribute:Attribute
{
private string _databaseName;
public string DatabaseName
{
get
{
return _databaseName;
}
}
private string _databaseConnexionString;
public string DatabaseConnexionString
{
get
{
return _databaseConnexionString;
}
}
public BusinessObjectAttribute(string databaseName)
{
this._databaseName = databaseName;
}
public BusinessObjectAttribute(string databaseName,
string databaseConnexionString)
{
this._databaseName = databaseName;
this._databaseConnexionString = databaseConnexionString;
}
}
}



After that we will create some refflection helpers in order to load the differents components of the assembly, such as the types and for each type the list of the members and so on.




--
Alain Lompo
Excelta - Conseils et services informatiques
MCT
MCSD For Microsoft .Net
MVP Windows Systems Server / Biztalk Server
Certifié ITIL et Microsoft Biztalk Server

Thursday, December 27, 2007

Les adaptateurs n/Sfotware pour Biztalk Server

Les adaptateurs n/software pour Biztalk Server contiennent des adapteur .Net pleinement managés qui s’intègrent parfaitement bien avec la pipeline de message de Biztalk Server. Ces adaptateurs étendent les fonctionnalités de Biztalk Server avec des possibilités de communications avancées et des possibilités de messagerie sécurisée. La toute nouvelle version 2.0 inclut l’usage d’adaptateurs dynamiques ou statiques, une intégration Biztalk améliorée et de nouvlles technologies de communication.

L’ímage suivante en dit long sur son architecture





Voici quelques caractéristiques des versions récentes

ü V 2.2 – Contient un nouvel adaptateur pour OFTP (Odette File Transfert Protocol)
ü V 2.1 – Contient un nouvel adaptateur pour l’intégration d’ Amazon Simple Storage Service (S3). S3 a été bâti sur la même infrastructure que celle utilisé par Amazone pour son propre réseau et fournit un stockage rapide, sécurisé et sur qui est accessible partout dans le monde.

Pour plus d’infos consultez le site à l’adresse : http://www.nsoftware.com/kb/tutorials/biztalkas2adapter.aspx

Cliquez sur le lien suivant pour télécharger la V2 : http://www.nsoftware.com/download/biztalk.aspx

Ou accédez à des tutorials ici : http://www.nsoftware.com/kb/tutorials/biztalkas2adapter.aspx

Labels: , , , ,

Wednesday, November 22, 2006

Comprendre les applications distribuées

Agenda
Breve historique
Applications client – serveur
Architectures distribuees
Technologies distribuees
L’abstraction “Objets distribues”
Avantages lies au developpement d’applications distribuees
Les defis du developpement d’applications n – tiers distribuees
Relever le defis a l’aide du .Net Remoting

Le developpement d’applications client serveur a constamment evolue au fil du temps pour satisfaire les contraintes d’entreprise de plus en plus importantes
Parmi les technologies initiales permettant de l’implanter on retrouve:
DCOM
Java
RMI
CORBA
Actuellement on exige des technologies de developpement d’applications client serveur d’etre
Efficientes
Extensibles
Dotees du support des transactions
Interoperable avec differentes tehnologies
Hautement configurables
Accessibles par Internet, ou intranet
….


Constats
---------

Rares sont les applications don’t le perimetre est suffisament large pour supporter l’ensemble des exigences mentionnees precedemment
Par consequent afin de prendre en compte les applications plus modestes la technologie client serveur
Doit fournir des comportement par defaut commun
Doit etre simple a configurer
Etre facile d’utilisation
Il est quasiment impossible de satisfaire a toutes les exigences mentionnees a l’aide d’une technologie unique
Par consequent les technologies modernes client – serveur commencent par implementer une liste d’exigences plus modestes, puis remplissent les autres exigences au fil des evolutions.
C’est l’approche adoptee par Microsoft .Net Remoting

Microsoft .Net Remoting
------------------------

Microsoft .Net Remoting a ete concu selon un model objet coherant et extensible offrant en outre la possibilite de developper des solutions logicielles client serveur similaires a celles qui se faisaient avec des technologies telles que DCOM
Elle exploite judicieusement les nombeuses technologies sous – jacentes offertes par la plate forme .Net Framework telles que
L’acces aux donnees a l’aide de Microsoft ADO .NET
La conception, le developpement, le deploiement et l’exploitation des services Web XML
L’utilisation des technologies d’acces distants tels que le Marshalling
L’utilisation des standards technologiques tels que XML, HTTP, SOAP

Microsoft .Net Remoting est le choix par excellence pour le developpement d’applications client serveur n – tiers ciblant la plate forme Microsoft .Net Framework

Interoperabilite du .Net remoting
----------------------------------

Lorsqu’on dispose d’objets COM/DCOM a reutiliser l’interoperabilite est assuree par une couche d’interoperabilitee integree en natif dans .Net Remoting possedant les caracteristiques suivantes :
Completude (richesse fonctionnelle)
Facilite d’utilisation
Offre des possibilites de migration progressive des objets des anciennes technologies vers .Net Remoting
Lorsqu’on dispose d’objets a reutiliser provenant d’une technologie non – Microsoft telle que Java Remote Method Invocation (RMI) ou Common Object Request Broker Architecture (CORBA), Microsoft .Net Remoting
Offre un support des technologies standardisees:
XML, SOAP (Simple Object Acces Protocol)
Qui permettent la communication entre notre application et toute plate forme supportant ces memes technologies

Architectures distribuees
-------------------------

On entend par application distribuee une application pour laquelle les traitements sont repartis entre deux ou plusieurs machines. Cette repartition des traitement impliquant notamment que les donnees concernees sont egalement distribuees.
Plusieurs architectures distribuees ont prevalu avant l’apparition du .Net Remoting, elle ont ete le fondement sur lequel Microsft apres avoir tire des lecons a developpe le .Net Remoting. Il s’agit notamment
De la programmation modulaire
Des applications client / serveur de base
Des applications client / serveur N – tiers
Du Peer – to – peer

Programmation modulaire
--------------------------

Principe : organiser le code en unites fonctionnelles coherantes
Les lignes de code en procedures
Les procedures en classes
Les classes en composants
Les composants en des sous – systemes plus vastes lies les uns aux autres
La modularite est tres utile pour la distribution du code sur differentes machines
Les architectures distribuees different essentiellement entre elles par les responsabilites attribuees a chaque module ainsi que leurs interactions

Client / serveur de base
------------------------

Represente l’architecture fondamentale ou primaire des applications distribuees
Definie par un processus client simple qui requiert des services de la part d’un processus serveur
De facon typique le processus client est responsible de la couche presentation interfaces utilisateur) ce qui inclut
La validation des entrees utilisateur
Le dispatchage des appels vers le serveur
L’execution potentielle de regles metiers
Le processus serveur quand a lui est responsible
De satisfaire les requetes du client en executant la logique metier et en interoperant avec des ressources telles que bases de donnees et fichiers
Il est classique d’avoir plusieurs client pour un seul processus serveur (exemple des applications Web)
D’un point de vue fonctionnel il est possible de faire cohabiter le client et le serveur sur la meme machine

Client / serveur N - tiers
--------------------------

Le client / serveur de base est appele “application 2 tiers” , car le client interagit directement avec le serveur.
Les applications 2 – tiers sont faciles a implementer mais ont une extensibilite limitee
Le cas d’utilisation suivant a conduit au besoin d’applications n – tiers
Une application s’execute sur une machine unique
Pour une raison quelconque on decide d’en faire une application distribuee
On souhaite par exemple donner acces a plus d’un client a la fois
Acceder a des ressources
Utiliser la puissance de traitement d’une machine aux configuration haut de gamme
Au fur et a mesure qu’on donne acces a des clients les processus de traitement ralentissent
A un certain moment les delais d’attente deviennent tellement importants que l’application est consideree indisponible
Pour resoudre le probleme on etend la configuration materielle: ce qui constitue une solution potentielle mais forcement temporaire
Une solution possible : l’usage d’une architecture n – tiers (3 tiers au moins)

On procedera donc a l’adjonction d’une couche intermediaire permettant la realisation de differentes taches
Y inserer la logique metier
La couche intermediaire dans ce cas s’assure de verifier la consistence des donnees fournies par le client et les utilise suivant les exigences du metier.
Peut impliquer une collaboration avec une couche donnees ou effectuer uniquement des traitement en memoire.
En cas de succes la couche intermediare transmet les donnees traiteees a la couche donnees pour stockage ou renvoie les resultats au client.
La force de cette conception : la distribution granulaire des responsabilites de traitement
Il est possible que plus d’une couche de cette architecture (2 par exemple) soient hebergees sur une meme machine
Dans ce cas aussi une separation logique des fonctions du systeme est avantageuse
Les developpeurs et les administrateurs peuvent maintenir les couches separement
Les changer, les deplacer simultanement
Les migrer vers des machines separees afin d’ameliorer l’extensibilite de la solution
Avantage indeniable pour extensibilite, et flexibilite de la maintenance et du deploiement


Architecture peer – to - peer
-----------------------------

Dans les architectures precedentes les roles sont distincts, on peut identifier un couple maitre/esclave entre client et serveur.
Les couches du modele n – tiers s’identifient souvent a des roles tels que couche presentation, couche metier ou couche donnees
Ceci n’est pas forcement indispensable
Certains models sont beaucoup plus collaboratif et il y est difficile de discerner la frontiere entre le client et le serveur
Les scenarios des groupes de travail sont bases sur ces modeles car leur objectifs est essentiellement le partage d’informations et de traitement
Le modele peer – to – peer est concu comme plusieurs noeuds individuels sans serveur centralise.
Ceci implique la necessite d’un mecanisme permettant aux differents noeuds de se reperer les uns les autres
Ceci est realise via des techniques de broadcasting ou des paramtres de configuration

Technologies distribuees
-------------------------

Plusieurs technologies ont servi au fil des annees a l’implantation des architectures presentees plus haut. Les meilleures ameliorations ont ete plus au niveau technologique qu’au niveau architectural, bien que des progres remarquables ont ete faits a ce niveau. Parmi celles – ci on a principalement
Les sockets
RPC (Remote Procedure Call )
Les Stubs
Le Marshalling
Les IDL (Interface Definition Languages)

Sockets
--------

L’une des abstractions fondamentales des applications reseau modernes
Barricadent les programmeurs de l’acces aux details de communication reseau de bas – niveau en la rendant similaire a des mecanismes I/O (Input Output)
Necessitent cependant beaucoup de travail pour developper une riche ou complexe application distribuee, bien que fonctionnellement parlant ils permettent un controle total de la communiquation
Les sockets demandent de creer des fonctions de transfert et reception de messages systemes ainsi que d’interpretation des flux de donnees
Les developpeurs ont besoin d’abstractions de haut niveau donnant l’illusion d’effectuer des appels de fonctions ou de procedures locales

Remote Procedure Call (RPC)
-------------------------------

La specification RPC a ete definie par la DCE (Distributed Computing Environment) et la Open Group (communement Open Software Foundation ). RPC permet
D’utiliser une semantique similaire a celle utilisee lors de la realisation d’appel local de procedure
Necessite cependant une configuration precise et implique des contraintes de type de donnees precis.
Les concepts fondamentaux introduits par RPC ont servi de fondement aux technologies de distributions telles que DCOM, CORBA, RMI et … Microsoft . Net Remoting, il s’agit principalement
Des stubs
Du Marshaling
Des IDL (Interface Defintion Language )
RPC constitue un bon important dans la tentative de rendre familieres les technologies de communication distantes par rapport aux Sockets. Mais vu les progres et la predominance de la P.O.O (Programmation Orientee Objet) le concept d’ “objets distribues” s’est impose

Stubs
----------

Bouts de code s’executant sur le serveur et le client et sont responsables de l’illusion que l’appel de la procedure distante est local.
Par exemple le code client appelle des procedures au sein du stub qui sont parfaitement ressemblantes a celles implementees sur le serveur
Le stub transfert ensuite l’appel a la procedure distante

Thursday, October 26, 2006

Biztalk Server 2006 exam intensive training

Hi,

If you are willing to take some Biztalk intensive training for certification, as I do, you can see on this web site, the course content is very interesting and the price seems to be nice also
http://www.quicklearn.com/deepdive.htm

Sql Server adapters for Biztalk Server

One of the greatest difficulties I found when I started working with BizTalk 2004 was the lack of documentation about the SQL Adapter. In this article, I'm going to demonstrate how we can use this adapter in an Orchestration of BizTalk.
The Example
To build this example, we're going to use the Northwind database. We're going to simulate a hypothetical situation where we receive an XML message as a file, containing the order number, a customer ID, and the date of the order. In the orchestration, we will use SQL
Server
to search the additional information about the customer, using the SQL Adapter.
Creating the Project
We'll start this article by creating a new BizTalk Server project in Visual Studio. In the Visual Studio .NET menu, select the "New Project" option, and for the type of project, select "BizTalk Projects". Select the template "Empty BizTalk Project" and create a project named OrderManager.
Creating the Schemas
Now that we have the project, we're going to create two maps that we'll use in the project, one for the input message and one for the output message.
Right-click on the project in the Solution Explorer, and select the "Add New Item" option, then select the "Schema" item. Create a schema named "IncompleteOrder".
Click on the root element of the schema and change the property "NodeName" to "Order". After that, right-click on this node and select the "Insert Schema Node" option. Inside this option, select "Child Field Element". Change the NodeName property of this new node to OrderId. Repeat this operation to create two additional elements named "OrderDate" and "CustomerId". Your schema should look like this:



Now, we're going to create the schema with the complete information of the order. Right-click on the project in the Solution Explorer and select the "Add New Item" option. Then, select the item "Schema" and name it "CompleteOrder".
When the schema shows up, rename the "Root" element to "CompleteOrder". After that, create the child elements: "OrderId", "OrderDate", "CustomerID", "CustomerName", "CustomerAddress", "CustomerCity", "CustomerCountry". The complete schema can be viewed in the image below:
Creating the test messages
In order to test our solution, we need to create some test messages. BizTalk Server is capable of creating these messages for us. Right-click on the "IncompleteOrder.xsd" schema in the Solution Explorer and select the "Properties" option. In the Properties, select the property "Output Instance Filename". In this field, type the value "C:\IncompleteOrder.XML". Click OK to close the window. Right-click on the schema file again in Solution Explorer and select the "Generate Instance" option. Open Windows Explorer and check if the file was created in the indicated place.
If you check the file created in Visual Studio, you'll see that the values generated are random. We're going to modify these values to use some valid information. Replace the OrderId field to the number 1. In the OrderDate field, type the value "2005-03-01", and in the field "CustomerId", the value "ALFKI". The XML file should have a similar structure as the file below:
1
2005-03-01
ALFKI

Save the file, we'll need it later.
Creating the structure to have access to the database
In order to use the SQL Server resources, we'll need to create a Stored Procedure capable of returning the data from the customer that we will place in the order.
Open the Enterprise Manager of SQL Server and select the Northwind database. Select the "Stored Procedures" applet, and right-click it, select the option "New Procedure". A new procedure should be created as follows:CREATE PROCEDURE proc_GetCustomer
(@CustomerId char(5))
AS
SELECT * FROM Customers
WHERE CustomerId=@CustomerId FOR XML AUTO, XMLDATA
GO
Don't forget to include the XMLDATA parameter in the end of the procedure, this will generate the necessary information for the SQL adapter. This parameter will be removed later.
Adding the structure to call SQL Server
Now that we've created all the necessary structures for the solution, we're going to create the structure to call SQL Server. For this, we will create a new item generated from the Solution Explorer. Right-click on the project in the Solution Explorer and select the "Add Generated Items" option. In the list of items, select the Add Adapter option and click on the Open button. The following screen will show up:


In this screen, select the adapter of type "SQL" and click Next (the other options can stay with default values, unless the database of your BizTalk server is in a remote server).
In the first screen, click on the Set button and provifde the information to connect to your SQL Server instance. Select "Northwind" as the initial catalog. When the connection string is set, click Next.
Th next screen shows information about the schemas that will be used to transport the information to and from SQL. In the Target Namespace option, type "http://nwtraders". In the Port-Type, select "Send Port", since we're going to send a request to SQL Server and receive a response. In the property "Request root element name", type "InCustomer", and in the property "Response root element name", type "OutCustomer".

Click on the Next button. In the screen "Statement type information", select the option "Stored Procedure". Click Next. In the combo box for selecting the procedure, select proc_GetCustomer. The stored procedure parameters will show up. Click on the first parameter (near the check box... do not check the check box, just click near it until the prompt appears) to enter the parameter information. Type "ANTON", that is a valid customer ID. Click on the Generate button and you will see that the script used to execute the procedure will show up in the bottom of the screen.

This information will be used by the SQL adapter to generate the initial schema, they are not used later in the project. Click on the Next button, and in the next screen, click the Finish button. A new schema and a new orchestration will be created in your project.
The created schema (SQLService) contains the request and response information for the stored procedure. The orchestration contains some types (port type) used to call the SQL adapter.
Updating the orchestration
Right-click on the orchestration in Solution Explorer and select the "Rename" option. Rename it to "ProcessOrder.odx".
Open the orchestration file and click on the white area in the orchestration designer (between the red and green indicators that indicate the end and beginning of the process). Check the property windows, and change the TypeName property from Orchestration_1 to ProcessOrderOrch.
Creating the necessary messages
In order to use our messages within the orchestration, it's necessary to create message variables. To do this, we'll need the Orchestration View window. Click on the "View" menu, select "Other Windows", and select the "Orchestration View" window.
In the orchestration view, right-click on "Messages" folder and select the New Message option. In the identification, type "msgIncompleteOrder" and select the "OrderManager.IncompleOrder" and its schema (the schema is available in the schemas item).
Create three additional messages with the following identifiers/schemas:
Identifier
Type
msgCompleteOrder
OrderManager.CompleteOrder
msgGetCustomerReq
OrderManager.procedureRequest (no item multipart messages)
msgGetCustomerResp
OrderManager.procedureResponse (no item multipart messages)
Creating orchestration elements
Now, we will create the elements used in the orchestration. In the toolbox, search for the "Scope" shape and drag it to just below the green indicator in the designer area. Rename the scope shape to "Do Updates". Change its transaction type to "None".
Now, drag a "Receive" shape from the toolbox to the area inside the scope shape. In the shape properties, set the properties below:
Name - Receive Incomplete Order
Message - msgIncompleteOrder
Activate - True
Just below the receive shape, drag a "Construct Message" shape. Use the following properties:
Name - Create SQL Request
Messages Constructed - msgGetCustomerReq
Now, drag a "Transform" shape inside the empty area inside the "Construct Message" shape. Select the "Input Messages" property and click the (...) button. A new window will open up with the mapping options. In the "Fully Qualified Map Name" box, type "ProcessOrder.IncompleteOrder_To_SQLRequest". Click on the "Source" option and select the "msgIncompleOrder" as the source message. Click on "Destination" and select the "msgGetCustomerReq" as the destination message. Your "Transform Configuration" screen should look like the one below. When you finish, click OK

In the map editor, drag the CustomerID field from the IncompleteOrder schema to the CustomerID field on the GetCustomerReq schema. Note that the destination schema represents the parameters used to call the stored procedure.

Save the map and go back to the orchestration file. Change the name of the "Transform" shape to "Create Request".
Now, we'll create a "Send" shape that will send our request to the SQL Server Adapter. Drag a new "Send" shape just below the construct message shape and use the following properties:
Name - Send SQL Request
Message - msgGetCustomerReq
After the Send Shape, create a new Receive Shape with the following properties:
Name - Receive SQL Resp
Message - msgGetCustomerResp
After the Receive shape, drag a new construct message with the following properties:
Name - Construct Response
Messages Constructed - msgCompleteOrder
Drag a new "Transform" shape to our newly created "Construct" shape. Select the property "Input Messages" and click on the (...) button. The transform configuration window will show up again. In the fully qualified name field, type ProcessOrder.SQL_To_CompleteOrder. In the Source option, select the "msgGetCustomerRep" and the "msgIncompleteOrder" (that is, two messages as source). Select the "Destination" option and select the "msgGetCustomerReq" option

Click OK and in the map editor, create a map with the necessary links

Close and save the map, and go back to the orchestration. Change the name of the "Transform" shape to "Create Response".
Now, we'll create a new "Send" shape that will send the final response to our customer. Create a new "Send" shape below the Construct Message shape, with the following properties:
Name - Send Response
Message - msgCompleteOrder

Biztalk Server adapter for Sharepoint Portal Server 2003

Microsoft® Office System 2003 and Microsoft Windows® SharePoint™ Services provide powerful features for publishing XML data within an organization. Microsoft® BizTalk® Server 2004 provides powerful features for consuming XML data, connecting to back-end systems, and orchestrating transactions among the systems. By combining Office System’s ability to create XML documents, SharePoint’ ability to store the XML documents, and BizTalk Server’s ability to process XML and communicate with hundreds of back-end systems, an organization can link the documents and tools familiar to knowledge workers with the enterprise systems that run the business.

The goal of this BizTalk Server adapter is to make it as easy to access XML documents stored in SharePoint libraries as it is to access files on a file server.
Architecture

The BizTalk Server 2004 Adapter Framework defines a consistent way to develop adapters. A “static adapter” consists of 3 elements: a receive function to accept documents, a transmit function to send documents and a schema that defines configuration settings. These three elements reside on the BizTalk Server.

On the SharePoint server, a web service is installed to provide access to the SharePoint libraries. The receive function calls a web method passing a SharePoint site name and folder and view, and the web method returns a list of filenames and a byte array for each file. The send function calls a web method, passing a SharePoint site name, folder, file name and byte array, and the web method returns the status of the operation. To maximize concurrency a simple check-out and delete protocol is used between the adapter and web service.





Receiving Documents from SharePoint
The receive adapter polls SharePoint folders. It calls a web method on the SharePoint server which uses the Windows SharePoint Server object model to browse the library, check out the files and return the file data to the adapter. The adapter then submits the files to the BizTalk Server Message Box and calls another web method to delete the files from SharePoint. In order to filter files in a SharePoint library, the adapter can poll the SharePoint library through a SharePoint view.


As an alternative to this polling architecture, the receive adapter could have been implemented as a SharePoint Event Handler. In that case, the Event Handler would forward documents to a well known location (queue, file, etc.) and BizTalk Server would process the documents from there.


Choosing between a polling or event-driven mechanism was driven by the trade-off between simplicity vs. performance. The centralized (polling) approach offers a simpler management model since all configuration is done on the BizTalk server and all errors are reported there. If Event Handlers were used, a system administrator, or automated scripts, would have to configure each document library to use them, and would have to configure the Event Handlers and BizTalk Server to communicate through a known location. Distributed change management would have to be put in place so that any changes made to the adapter can be deployed in the enterprise.


Given that linking SharePoint documents to business processes is probably not a high throughput task, this design favors simplicity over performance. That said, we tested performance of the receive handler and were able to process 10 documents per second on a SharePoint server with 2xCPU @ 3GHz with SQL Server EE onboard. Specifically, we set the batch size to 50 and the polling interval to 5 seconds and pointed the receive location at a SharePoint folder with thousands of documents. In order to achieve this performance level, we did significant optimization using the SharePoint Object Model in the custom web service residing on the SharePoint server.

Note that because platform level transaction support is not available across SharePoint, Web Services, and BizTalk Server, the check-out mechanism is used to minimize errors associated with failure conditions. Under certain conditions, (i.e., files are successfully sent into the BizTalk Server message box but cannot be deleted from SharePoint) the files will remain checked-out on the SharePoint server even though they were submitted to BizTalk Server. Errors will be logged to the event log on the BizTalk server, but no garbage collection algorithm was implemented.
Sending Documents to SharePoint
The adapter sends documents to SharePoint by calling a web method on the SharePoint server. The adapter specifies the SharePoint site, file name and promoted properties to associate with the file.
The adapter can set the filename to a fixed string or to a name derived from the XML data in the document. Deriving the name can be very useful to enforce standard naming conventions. The adapter can also set promoted property values on the file after it’s written to the SharePoint library. As with the file names, the promoted property values can be fixed or can be derived from the XML data in the document.


Setting SharePoint promoted property values from the Send adapter, in conjunction with using the SharePoint Views in the Receive adapter, can be very useful for using BizTalk Server to read and write files to the same SharePoint folder. For instance, if a “status” column in SharePoint folder defaults to blank, and a SharePoint view is defined to pick up only files where status=””, then the Receive adapter can use this view to pick up files and the send adapter can set the column to “Processed”. In this way, once the Send adapter writes the file, the Receive adapter will not pick it up again. Note that if the view used by the receive adapter is not coordinated with the properties set by the send adapter, you could end up with an infinite loop.
It’s important to note that Promoted Properties in SharePoint are different entities than Promoted Properties in BizTalk Server. SharePoint Promoted Properties are used to make XML elements visible when browsing a SharePoint Forms library. When an InfoPath form is published to a SharePoint Forms library, InfoPath can configure the Forms Library to promote key elements, making this happen automatically.


When using this adapter with InfoPath forms and Forms Libraries (rather than arbitrary XML and Document Libraries), it’s not necessary to set the promoted properties through the send adapter. Instead, the value of BizTalk Promoted Properties can be set within Orchestration, and those values will be automatically promoted by SharePoint. For more information about SharePoint promoted properties, see http://msdn.microsoft.com/library/en-us/spptsdk/html/tsptFormLibraries.asp

Installing the Adapter
Two components comprise the adapter: a .DLL that is installed on the BizTalk server and a Web Service that is installed on the Windows SharePoint Server. Each component has a simple setup procedure defined below. Additionally, if the Web Services is to be used by other programs, or if it will be edited by Microsoft® Visual Studio® .NET, then additional setup steps are necessary.
1. Unpack the distribution file, WSSAdapter.exe. It contains three self-extracting files; one with the deployment artifacts, one with the source code and one with samples. This section describes how to install the deployment artifacts. The source code is provided for reference. The samples each have their own setup program.
Deploy on the BizTalk Server
2. Unpack the deployment distribution, WSSAdapterDeploy.exe. If you unpack it to the default location, then SharePointAdapter.REG points to the right location. If you unpack it to a different location, edit SharePointAdapter.REG to adjust the following 3 file references in the .REG file: AdapterMgmtAssemblyPath, InboundAssemblyPath, OutboundAssemblyPath.
3. Run SharePointAdapter.REG from C:\Program Files\Microsoft BizTalk Server 2004\SDK\Samples\Adapters\SharePoint\SharePoint Adapter to merge the data into the registry so that BizTalk Server can find the adapter at design time and runtime.
4. Add the new adapter into BizTalk Server
a. In the BizTalk Server Administration Tool. Name it WSSLib and select WSSLib from the list of installed adapters.
b. Stop and start the BizTalk service so it picks up the new adapter.
c. If Visual Studio .NET is open, close it and reopen it so that the new Adapter is available to the BizTalk Explorer.
Deploy on the Windows SharePoint Services Computer
5. Copy WSSDocLibServices.ASMX from the c:\Program Files\Microsoft BizTalk Server 2004\SDK\Samples\Adapters\SharePoint\SharePoint WebServices\WSSWebServices\ to the _vti_bin folder in the default web site on the Windows SharePoint Services computer. By default, _vti_bin is mapped to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI\ but you can verify this mapping by right-clicking on the _vti_bin application in the default web site in IIS Manager, as shown below:

6. Copy WSSDocLibServices.DLL from the c:\Program Files\Microsoft BizTalk Server 2004\SDK\Samples\Adapters\SharePoint\SharePoint WebServices\WSSWebServices\ to the _vti_bin\bin folder on the Windows SharePoint Services computer. This DLL goes must reside in the \bin folder under the folder where you just placed the .ASMX file in the previous step.
7. To verify that the web service is installed properly, browse to the URL where you placed the WSSDocLibService.asmx file in the previous steps. You can do this in IIS manager, by right clicking on the WSSDocLibService.asmx and selecting Browse, or by pointing your browser to the correct URL (like http://[:port]/_vti_bin/WSSDocLibService.asmx). However you get there, you see the web methods that the web service exposes.
The BizTalk Server Adapter for SharePoint Libraries is now ready to use. Receive Location and Send Ports can be configured to access SharePoint libraries in a similar way that they are configured to access file system folders.
Configuration and Use
This adapter leverages the BizTalk Server Adapter Framework and is accessed directly from Visual Studio .NET and the BizTalk Server Administration Tool.
Receive
Receive locations are used to define where and how the adapter looks for files. The adapter polls for files, runs the pipeline and sends the messages into the BizTalk Server Message Box. Table 1 describes the configuration properties of the Receive Locations. Table 2 describes the configuration properties of the Receive Adapter.
Configuration
Property
Description
Archive Folder Name
Folder name within the SharePoint site in which to copy the file after it has been successfully submitted to the BizTalk Message Box. For example, Archived Documents
Error Threshold
Number of times the adapter will call the web service before disabling the receive port.
Polling Interval
Number of seconds to sleep between web method calls to GetDocuments.
Site Address URL
URL of the SharePoint site polled for files. For example, http://localhost/sites/accounting/
Site Folder Name
Folder name within the SharePoint site from which documents are received. For example, Shared Documents
View Name
View defined in the SharePoint site that filters files. For example, a view named NewOrders may return the list of files that have their OrderStatus field set to “New”.
Table 1 – Receive Location Properties

Property
Description
Debug level
Controls the amount of information written to the event log by the adapter. This is in addition to the information written by the BizTalk engine.
Polling Interval
Number of seconds to sleep between web method calls to GetDocuments. This is the default value for Receive Locations.
Receive Batch Size
Number of files to request from SharePoint with each call to the web service.
Table 2 – Receive Adapter Properties
Send
Send Ports are used to define the location into which the adapter writes files. The adapter first resolves the file name and promoted property values and then calls a web method to post the files to SharePoint and set the promoted properties.

Property
Description
Name
Base name of the file. Can be literal string or an XPATH Query. If it’s a literal, a %GUID% token will be replaced by a new GUID. If it’s an XPATH Query, it must be preceded by an ‘=’.
Extension
Extension to append to file name. Defaults to XML.
Namespace
Namespace that is used to resolve the XPATH Query, if the Name is an XPATH. Must be in form pre=ns.
Table 2 – File Name Properties

Property
Description
Overwrite
Boolean flag indicating whether the adapter should overwrite a file if one with the same name already exists. Defaults to True.
Site Address URL
URL of the SharePoint site that contains the folder to which documents are written. For example, http://localhost/sites/accounting/
Site Folder Name
Folder name within the SharePoint site to which documents are written. For example, Shared Documents
Table 3 –Location Properties


Property
Description
Property #n Name
Name of the SharePoint promoted property in a SharePoint library that will be set.
Property #n Source
Value to set into the SharePoint promoted property. This can be a literal string or can be an XPATH Query. If it’s an XPATH Query, it must be preceded by an ‘=’.
Property #n Source NameSpace
Namespace that is used to resolve the XPATH Query, if the Property #n Source is an XPATH. Must be in form pre=ns.
Table 4 –Promoted Properties

As described in the tables above, the file name and values of the SharePoint promoted properties can be set as either a literal string or as an XPATH query that will be passed to SelectSingleNode method off of the document root. If the 1st character of the value is an ‘=’, the adapter treats it as an XPATH query and attempts to resolve the value by calling SelectSingleNode. If the 1st character is anything else, the adapter treats it as a literal string. When specifying an XPATH query, an XML Namespace may be required, depending on the schema used by the XML instance document. Because the syntax of XPATH can be difficult to derive by hand, you should verify the correct XPATH Query and the Namespace before specifying them in the Send ports.

Using the Adapter
There are two samples included with the adapter.
In one sample, InfoPath is used to fill out an absence request form whose template is stored in a SharePoint Forms Library. When the form is completed, it is saved to the SharePoint Forms library and the SharePoint promoted properties are automatically displayed as columns in the Forms Library. BizTalk Server asynchronously picks up the form using the Receive Adapter, makes a decision based on the data, updates data on the form, and uses the Send Adapter to write it back to SharePoint.
In the other sample, Excel 2003 is used to create an expense report. A “submit” button in the spreadsheet saves the XML data to a SharePoint Document Library. After Excel saves the file, BizTalk Server asynchronously picks up the form using the Receive Adapter, and unconditionally sends it to another SharePoint folder through the Send Adapter. The Send Adapter is configured to set SharePoint Promoted properties and the filename based on contents of the XML file.

Tuesday, October 17, 2006

.NET Building Blocks is a set of core Internet Services.
Web Services
Web Services provide data and services to other applications.
Future applications will access Web Services via standard Web Formats (HTTP, HTML, XML, and SOAP), with no need to know how the Web Service itself is implemented.
Web Services are main building blocks in the Microsoft .NET programming model.
Standard Communication
Official Web standards (XML, UDDI, SOAP) will be used to describe what Internet data is, and to describe what Web Services can do.
Future Web applications will be built on flexible services that can interact and exchange data, without the loss of integrity.
Internet Storages
.NET offers secure and addressable places to store data and applications on the Web. Allowing all types of Internet devices (PCs, Palmtops, Phones) to access data and applications.
These Web Services are built on Microsoft's existing NTFS, SQL Server, and Exchange technologies.
Internet Dynamic Delivery
Reliable automatic upgrades by demand and installation independent applications.
.NET will support rapid development of applications that can be dynamically reconfigured.
Internet Identity
.NET supports many different levels of authentication services like passwords, wallets, and smart cards.
These services are built on existing Microsoft Passport and Windows Authentication technologies.
Internet Messaging
.NET supports integration of messaging, e-mail, voice-mail, and fax into one unified Internet Service, targeted for all kinds of PCs or smart Internet devices.
These services are built on existing Hotmail, Exchange and Instant Messenger technologies.
Internet Calendar
.NET supports Internet integration of work, social, and private home calendars. Allowing all types of Internet devices (PCs, Palmtops, Phones) to access the data.
These services are built on existing Outlook and Hotmail technologies.
Internet Directory Services
.NET supports a new kind of directory services that can answer XML based questions about Internet Services, far more exactly than search engines and yellow pages.
These services are built on the UDDI standard.

Tuesday, June 13, 2006

New nice stuffs in Biztalk Server 2006

With the March 2004 release of BizTalk Server 2004, the third generation of the Microsoft business process integration server, customers gained the benefits of integration with Microsoft Visual Studio .NET 2003 and the Microsoft Office System. BizTalk Server 2004 also enhanced the existing business process orchestration functionality, introduced new capabilities for business activity monitoring (BAM), enabled human-based workflow, and provided a highly scalable rule engine. Today, applications built with BizTalk Server 2004 run on the Microsoft .NET Framework. This makes it easier for customers to automate and manage complex business processes by using the BizTalk Orchestration Engine to integrate applications, trading partners, and employees.

BizTalk Server 2006 builds on the core architecture of BizTalk Server 2004 and makes strides in all dimensions of application-to-application, business-to-business, and business-process automation. This topic describes the new and enhanced features available with BizTalk Server 2006.

BizTalk Server 2006 helps you get started faster. With a simplified installation wizard, a component updater, and one-click configuration, installing and configuring BizTalk Server is more straightforward and efficient than ever before.
The following are the new and enhanced features available for setup and configuration.
Setup

Component updater technology that checks for missing prerequisite components and installs them automatically from the Web or from a pre-downloaded CAB file
More flexibility for multicomputer installations
Seamless upgrade from BizTalk Server 2004
Automatic installation of 64-bit software on 64-bit operating systems
Ability to install 32 and 64-bit engine components side-by-side on 64-bit computers
Configuration

Default configuration that is targeted for new developers
New feature-based user interface (UI) that presents a consolidated view of each feature
Ability to selectively configure or unconfigure each feature
Consolidated views for databases and service accounts
Reentrant design allows you to go back to change settings or edit configuration options after the initial configuration is complete.
Better Management and Operations
BizTalk Server 2006 provides new capabilities that enable the IT administrator to be more productive in managing and operating an enterprise deployment. A new management console delivers enhanced support for management, monitoring, and deployment of BizTalk servers and the applications on which they run. With BizTalk Server 2006 you can package complete applications into .msi file packages using Microsoft Windows Installer. The use of .msi file packages replaces the SEED capabilities provided in previous releases of BizTalk Server. SEED is not shipped in BizTalk Server 2006.

The following are the new and enhanced features available for management and operations.
Microsoft Management Console (MMC) administration
A single management tool for configuring, deploying, managing, and monitoring your BizTalk Server applications
Task-based design provides easy access to your most common tasks
Integrated hub page or dashboard that summarizes system health
Powerful querying capabilities for performing root-cause analysis
Updated management pack for use with Microsoft Operations Manager (MOM) 2005
Support for remote configuration and administration of multiple BizTalk groups
Support for bulk operations greatly speeds up remediation of errors
Support for clustering BizTalk Hosts that provide 100 percent availability
Ability to view message properties, body, and parts in the message viewer
Enhanced error and event reporting with the exception message box capabilities built in
BizTalk messaging services can be clustered to better support high availability
Addition of a limited-privilege BizTalk Operator role for administration
Tracking and reporting APIs
Visual Studio is no longer required or recommended in the production environment
Application concept
Introduction of the BizTalk application, which is a collection of BizTalk Server artifacts for simplified deployment, management, and troubleshooting
Ability to quickly import and export a BizTalk application
Application-based views of errors in message processing
Application deployment
One-click start and stop operations for deploying and undeploying BizTalk applications.
Built-in support for deploying all BizTalk Server artifacts, including COM components, ad-hoc scripts, and generic files
Ability to package and deploy applications across servers that use Windows Installer technology
New deployment command line tool
Empowerment for Business Users
BizTalk Server 2006 empowers the business user by extending capabilities introduced in BizTalk Server 2004, such as Business Activity Services (BAS) and BAM; providing better integration with Windows SharePoint Services; and providing real-time support for business activity subscriptions and notifications.
The following are the new and enhanced features available for business users.
Business Activity Monitoring (BAM)
Proactive business alerts and notifications support
New customizable BAM portal built on ASP.NET 2.0 technology
Operations integration enables escalation from BAM operator to IT administrator
New BAM addin for Excel
Enhancements to the BAM Manager
Support for messaging and message tracking
Tracking Profile Editor (TPE)
Ability to retrieve activities from the BAM database
Activity-centric design
Support for messaging
Business Activity Services (BAS)
Enhancements to the BAS Web site that provide tighter integration with the new Windows SharePoint Services adapter
Support for preconfigured send ports, called mapped ports
Improvements in the parameter service that provide support for structured, typed parameters
Inclusion of a Message Repair sample from SWIFT
Improvements in the Microsoft Office InfoPath UI
Integration with new BizTalk Server setup & deployment tools for a single, BizTalk Server wide deployment solution
Orchestration Designer for Business Analysts (ODBA)
Ability to model high-level business process workflows:
Create business process workflows using ODBA
Export ODBA workflows to BizTalk Orchestration Designer (OD)
Import existing orchestrations from OD to ODBA for documentation purposes
Improved layout provides an enhanced first-time design experience together with the capability to read imported orchestrations
Support for BAM Activity Definition XML
Ability to associate ODBA milestones with high-level actions in process visualization
Ability to define global "data of interest" list
Import XML into Excel at design time to avoid duplication of data entry in Excel
Invoke BAM Web pages directly from ODBA
Empowerment for Developers
BizTalk Server 2006 empowers the developer by providing upgraded, more powerful versions of established BizTalk developer tools built on top of the latest .NET Framework and Visual Studio 2005. BizTalk Server 2006 includes new tools such as the Flat File Schema Creation Wizard and new adapters like the Windows SharePoint Services adapter.
The following are the new and enhanced features available for developers.
Orchestration Designer improvements
Zoom support
Ability to preserve collapsed and expanded shapes across save operations
Ability to call pipelines from an orchestration for outbound batching support
New adapters
POP3 receive adapter
Windows SharePoint Services adapter
Enhancements in existing adapters
Message Queuing adapter and IBM MQSeries adapter now ship in the box
More granularity in the performance counters for all adapters
SMTP adapter enhancement:
Enhanced e-mail composing
File adapter enhancements:
Ability to connect to UNC shares using alternative credentials
Migration of several registry keys to property pages that can be modified in the UI
Directory browse button
HTTP adapter enhancements:
Ability to optionally suspend failing requests
Migration of BatchSize registry key to the UI
SOAP adapter enhancements:
Ability to call Web services without orchestrations (messaging-only scenarios) by using content-based routing (CBR) send ports
Ability to call Web services that have array-type parameters
IBM MQSeries adapter enhancements:
Uses "dynamic send" capability to dynamically receive messages from a queue
Ability to receive messages based on Match options
Ability to create queues in Windows MQSeries Queue Manager from within orchestrations or pipeline components
MSMQT adapter enhancement:
Ability to easily remove the MSMQT adapter
Other developer enhancements
Flat-File Schema Creation Wizard
Visual Studio 2005 support only; runtime built on .NET Framework 2.0
Automated solution level redeploy
BAM SQL Views and Operations APIs provide support for custom monitoring tools
Deeper Windows Server System Support
BizTalk Server 2006 provides deeper support of the Microsoft Windows Server System integrated server software by including an x86-based 64-bit version of the Windows Server 2003 operating system, and by supporting the latest versions of Microsoft SQL Server 2005, Microsoft Visual Studio 2005, and Microsoft Virtual Server 2005.
The following are the enhancements in Windows Server System support.
Supported platforms
The following 64-bit processors are supported:
AMD64 (x86-64)
Extended Memory 64-bit Technology (EM64T)
Note
Intel Architecture-64 (IA64) is not supported.
.NET Framework 2.0
Windows Server 2003 R2
Visual Studio 2005
SQL Server 2005 and 2000

Other Important Enhancements
The following are some other new and enhanced features available with BizTalk Server 2006.
Messaging Engine and core enhancements
Ability to resume more types of failed and suspended messages
Ability to route failed messages together with detailed error information for automated error handling
Support for routing messages with errors to business owners for correction, instead of suspending them
In-order delivery for all transport types that preserves the message order from the publisher to the subscriber
Nonatomic and recoverable interchange processing
Large message transformation
Engine throttling
Transactional pipelines
Execution of pipelines from within orchestrations
New and more detailed performance counters
Enhanced error-handling functionality
Fewer tools and manual tasks
Resubmit capability
Improved run-time scalability when tracking is enabled
Orchestration engine can add message parts dynamically
Enterprise Single Sign-On (SSO)
Password synchronization capability
Non-Windows, or host-initiated SSO
MMC snap-in for management – based on MMC 3.0
Client UI for end users
Ability to specify multiple accounts for access accounts
Extension in group type affiliate application to specify multiple mappings
Remote IssueTicket capability
Ability to specify ticket time-out at the affiliate application level
Back-up secret capability in configuration UI

Thursday, May 04, 2006

Speaking on Windows Presentation Fundation at Casablanca March MSDN session


I have been speaking on Windows Presentation Fundation at Casablanca MSDN session on March the 26th with Ali and Youness. Windows Presentation Fundation is really an amezing Framework, and it intelligent usage of XAML has taken the user experience to a wonderful unreached level. And I was the humble technology servior who had the task of presenting it. People liked it and so did I. Ali and Youness were also well done on Windows Communication Fundation and Windows Workflow Fundation. Great experience at all !!!!