In the past days I have been installing ESB toolkit 2.0 for BizTalk Server 2009. In 2009 classic environment all seems to work fine but what’s the matter if I want to enjoy Exception Management Framework and ESB.Portal in 2006 R2 environment?

Hereunder  my “2006 R2” machine :

• Windows Server 2003

• Microsoft .NET Framework 3.5 SP1

• IIS 6.0

• Microsoft SQL Server 2005

• Microsoft BizTalk Server 2006 R2

• Microsoft Visual Studio 2008 SP1

• Microsoft Chart Controls for Microsoft .NET Framework 3.5

Ok, let’s get started

1) install/import Microsoft.Practices.ESB.ExceptionHandling.msi

2) With VS 2008 : install powershell 1.0 in order to run ESBSource\Source\Samples\Management Portal\Install\Scripts\Management_Install.cmd

Without VS 2008 : create that 4 virtual dir with the same application pool  (see Management_Install.ps1 for details) and build ASP.NET project on separate machine

3) deploy bam act and views,ecc.. with  bm deploy-all -DefinitionFile:”C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bam\Microsoft.BizTalk.ESB.BAM.Exceptions.xml”

4) Now, run ESB configuration tool … ERROR!

ESB configuration tool works with SQL.DMO 10.0 that require native client 2008 e SQL Types 2008.

Excluding core components,  ESB configuration tool creates :

- EsbExceptionDb and roles

- ESB.ExceptionHandlingServices (with its dedicated app pool)

- ESB.ExceptionHandlingServices.WCF (with its dedicated app pool)

We can manually set that configuration or install SQL Native Client 2008, SQL Types 2008 and SQL.DMO 2008 ( download  http://www.microsoft.com/downloads/details.aspx?familyid=228DE03F-3B5A-428A-923F-58A033D316E1&displaylang=en )

5) Check the service : http://localhost/ESB.ExceptionHandlingServices/ExceptionHandling.asmx .. it works

6) Check http://localhost/ESB.ExceptionHandlingServices.WCF/ExceptionHandling.svc … ERROR

Edit web.config file adding in <system.web> section

<trust level=”Full” originUrl=”"/>

7) check http://localhost/ESB.Exceptions.Service/ExceptionService.svc  .. it works

check http://localhost/ESB.Portal  …

ERROR:  The HTTP request is unauthorized with client authentication scheme ‘Negotiate’. The authentication header received from the server was ‘NTLM’.

cscript c:\inetpub\adminscripts\adsutil.vbs set w3svc/NTAuthenticationProviders “Negotiate,NTLM”

ERROR : looking at EsbExceptionDb I see that one store procedure miss. Creating it all works fine!

Remember to change Destination Location of ExceptionHandling.PipelineComponents.dll From “BizTalk Server 2009″ to 2006

Now I can enjoy ESB.Exception and ESB.Portal with 2006 R2!

Crossing boundaries is an expensive operation because it can constitute various elements such as data marshaling, security, physical location, and so on. Some of the design principles to keep in mind vis-à-vis the first tenet are as follows:

- Know your boundaries: A well-defined and published public interface is the main entry point into the service, and all interactions occur using that.

- Services should be easy to consume: It should be easy for other developers to consume the service. Also, the service interface should allow the ability to evolve over time without breaking existing consumers of the service.

- Avoid RPC interfaces: Instead, use explicit messages.

- Keep the service surface area small: Provide fewer public interfaces that accept a well-defined message, and respond likewise with a well-defined message. As the number of public interfaces grows, it becomes increasingly difficult to consume and maintain the service.

- Don’t expose implementation details: These should be kept internal; otherwise, it will lead to tight coupling between the consumer and the service.

TENET 2: SERVICES ARE AUTONOMOUS

Services are self-contained and act independently in all aspects such as deploying, versioning, and so on. Any assumptions made to the contrary about the service boundaries will most likely cause the boundaries to change themselves. Services need to be isolated and decoupled to accomplish the goal of making them autonomous.

The design principles to keep in mind for the second tenet are as follows:

• Service versioning and deployment are independent of the system in which they are deployed.

• Contracts, once published, should not be changed.

• Adopt a pessimistic approach, and isolate services from failure.

TENET 3: SERVICES SHARE THE SCHEMA AND CONTRACT, NOT THE CLASS

Services interaction should be using policies, schemas, and behaviors instead of classes, which have traditionally provided most of this functionality. The service contract should contain the message formats (defined using an XML schema), message exchange patterns (MEPs, which are defined in WSDL), any WS-Policy requirements, and any BPEL that may be required. The biggest challenge you face is the stability of the service, once it has been published. It gets difficult to change it then without impacting any of the consumers.

The design principles to keep in mind for the third tenet are as follows:

• Service contracts constituting data, WSDL, and the policy do not change and remainstable.

• Contracts should be as explicit as possible; this will ensure there is no confusion over the intent and use of the service. Additional contracts should be defined for newer versions of the server in the future.

• If breaking service contracts is inescapable, then version the services because this minimizes the ripple to existing consumers of the service.

• Do not expose internal data representation publicly; the public data scheme should be absolute.

TENET 4: SERVICE COMPATIBILITY IS BASED ON POLICY

At times you will not be able to express all the requirements of service interaction via WSDL alone, which is when you can use policies. Policy expressions essentially separate the structural and semantic compatibility. In other words, they separate “what is communicated” and “how/whom a message is communicated.” A policy assertion identifies a behavior of a policy entity and provides domain-specific semantics. When designing a service, you need to ensure that policy assertions are as explicit as possible regarding service expectations and semantic compatibilities.

Basic binding 

Offered by the BasicHttpBinding class, this is designed to expose a WCF service as a legacy ASMX web service, so that old clients can work with new services.

TCP binding

Offered by the NetTcpBinding class, this uses TCP for cross-machine communication on the intranet. It supports a variety of features (reliability, transactions, and security) and is optimized for WCF-to-WCF communication (client and service must use WCF).

Peer network binding

Offered by NetPeerTcpBinding class

IPC binding

Offered by the NetNamedPipeBinding class, this uses named pipes as a transport for same-machine communication. It is the most secure binding since it cannot accept calls from outside the machine and it supports a variety of features similar to the TCP binding.

Web Service (WS) binding

Offered by the WSHttpBinding class, this uses HTTP or HTTPS for transport, and is designed to offer a variety of features such as reliability, transactions, and security over the Internet.

Federated WS binding

Offered by the WSFederationHttpBinding class, this is a specialization of the WS binding, offering support for federated security.

Duplex WS binding

Offered by the WSDualHttpBinding class, this is similar to the WS binding except it also supports bidirectional communication from the service to the client.

MSMQ binding

Offered by the NetMsmqBinding class, this uses MSMQ for transport and is designed to offer support for disconnected queued calls.

MSMQ integration binding

Offered by the MsmqIntegrationBinding class, this converts WCF messages to and from MSMQ messages, and is designed to interoperate with legacy MSMQ clients.

Bindings : transport and encoding

Set pipeline component property

#002 Error: 2 (Miscellaneous error) 70: Missing or invalid Transaction set identifier
Res: nelle EDI GLOBAL PROPERTIES oppure nelle proprietà della specifica PARTY impostare il valore di sender (2221111000001) per il segmento UNB2.1 (identification)

#003 Error: 3 (Miscellaneous error) 71: Transaction Set or Group Control Number Mismatch
Res: il valore “Message reference number” nella sezione UNT deve corrispondere al valore nella sezione UNH (UNH+8+INVOIC:D:96A:UN:EAN008′ … UNT+1516+8′)

#004 Error: 4 (Miscellaneous error) …………..
Res : il valore “Interchange reference number” nella sezione UNZ deve corrispondere al valore nella sezione UNB (UNB+UNOA:3+2221111000001:14+011111:ZZ+080328:1200+8++++++1′ …. UNZ+3+8′)

#005 Error: 5 (Miscellaneous error) 29: Invalid count specified at interchange, group or message level
Res: nel segmento UNT+234+12′ il contatore di segmenti contiene un valore errato (234).

#006 Error: 6 (Field level error) 21: Invalid character found
#007 Error: 7 (Field level error) 37: Invalid character(s) found in data element
Res : Errore nell’encoding. Il valore specificato nell’istanza non consente un insieme più ristretto di caratteri rispetto a quanto presente nel corpo del messaggio (UNB+UNOB:3+2221111000001:14+011111:ZZ+080328:1200+8++++++1′)

/* ———————————-
Funzioni utilizzate nello script seguente:
- GetRoot()
- GetAncestor(n)
- GetDescendant(childA, childB)
- GetLevel()
- ToString()
- IsDescendant()
- Reparent(oldParent, newParent)

———————————- */

– Creazione tabella Employee

CREATE TABLE HR.Tb_Employee2008
(
EmployeeNode hierarchyid,
EmployeeId int,
NtUserName nvarchar(50),
Title nvarchar(100),
CONSTRAINT PK_TbE_EmployeeNode PRIMARY KEY CLUSTERED (EmployeeNode)
)

– Inserisco il nodo root

INSERT HR.Tb_Employee2008 (EmployeeNode, NtUserName, Title)
VALUES(hierarchyid::GetRoot(), ‘DOMSTAR\Bob’, ‘Big Boss’)

DECLARE @Manager hierarchyid
DECLARE @LastCreatedEmp hierarchyid
DECLARE @ManagerUserName nvarchar(50)SET @ManagerUserName = ‘DOMSTAR\Bob’

– Ricavo il HieId del manager

SELECT @Manager = EmployeeNode
FROM HR.Tb_Employee2008
WHERE NtUserName = @ManagerUserName

– Ultimo nodo aggiunto al Manager

SELECT @LastCreatedEmp = MAX(EmployeeNode)
FROM HR.Tb_Employee2008
WHERE EmployeeNode.GetAncestor(1) = @Manager ;

– Aggiungo un nodo a partire da un determinato manager

INSERT HR.Tb_Employee2008 (EmployeeNode, NtUserName, Title)
VALUES(@Manager.GetDescendant(@LastCreatedEmp, NULL), ‘DOMSTAR\Ada’, ‘Sales Manager’)

– GETLEVEL function

SELECT
EmpLevel = EmployeeNode.GetLevel(),
HierarchyText = EmployeeNode.ToString(),
*
FROM
HR.Tb_Employee2008
ORDER BY
HierarchyText

– GETANCESTOR(n) function (nodi di livello n)

DECLARE @Manager hierarchyidSELECT @Manager = EmployeeNode
FROM HR.Tb_Employee2008
WHERE NtUserName = ‘DOMSTAR\Eric’

SELECT EmployeeNode.ToString(), NtUserName
FROM hr.Tb_Employee2008
WHERE EmployeeNode.GetAncestor(2) = @Manager ;

– ISDESCENDANT Employees che dipendono da un manager

WHERE @manager.IsDescendant(EmployeeNode) = 1

– REPARENT (muove un nodo)

DECLARE @EmpToMove hierarchyid
DECLARE @OldParent hierarchyid
DECLARE @NewParent hierarchyidSELECT @EmpToMove = EmployeeNode
FROM HR.Tb_Employee2008
WHERE NtUserName = ‘DOMSTAR\John’

SELECT @NewParent = EmployeeNode
FROM HR.Tb_Employee2008
WHERE NtUserName = ‘DOMSTAR\Marie’

SELECT @OldParent = EmployeeNode.GetAncestor(1)
FROM HR.Tb_Employee2008
WHERE EmployeeNode = @EmpToMove

UPDATE HR.Tb_Employee2008
SET EmployeeNode = @EmpToMove.Reparent(@OldParent, @NewParent)
WHERE EmployeeNode = @EmpToMove ;

Eseguendo la seguente la SELECT :

SELECT
EmpLevel = EmployeeNode.GetLevel(),
HierarchyText = EmployeeNode.ToString(),
*
FROM
HR.Tb_Employee2008
ORDER BY
HierarchyText

si ottiene

SELECT
SchemaName = SCHEMA_NAME(TB.schema_id),
TableName = TB.name,
TableHasForeignKey = OBJECTPROPERTY(TB.object_id,‘TableHasForeignKey’),
TableHasForeignRef = OBJECTPROPERTY(TB.object_id,‘TableHasForeignRef’),
TableHasClustIndex = OBJECTPROPERTY(TB.object_id,‘TableHasClustIndex’),
TableHasNonclustIndex = OBJECTPROPERTY(TB.object_id,‘TableHasNonclustIndex’),
TableHasIdentity = OBJECTPROPERTY(TB.object_id,‘TableHasIdentity’),
TableHasPrimaryKey = OBJECTPROPERTY(TB.object_id,‘TableHasPrimaryKey’),
TableHasUniqueCnst = OBJECTPROPERTY(TB.object_id,‘TableHasUniqueCnst’),
modify_date
FROM sys.tables TB
WHERE
OBJECTPROPERTY(TB.object_id,‘TableHasIndex’) = 1
AND OBJECTPROPERTY(TB.object_id,‘IsSystemTable’) = 0
ORDER BY TableName