BizTalk querry to get details related to map.

GET SEND PORT DETAILS BY MAP NAME
-----------------------------------------------------------

select

app.nvcName as ApplicationName,

sp.nvcName as SendPortName,

item.FullName as MapName,

map.indoc_docspec_name,

map.outdoc_docspec_name,

sp.nvcFilter

from bts_sendport as sp

inner join bts_sendport_transform as spt on sp.nID = spt.nSendPortID

inner join bts_application as app on app.nID = sp.nApplicationID

left outer join bt_MapSpec as map on map.id = spt.uidTransformGUID

left outer join bts_item as item on item.id = map.itemid

where item.FullName like '%MAP NAME%' -- 1 RECORD WITH THIS CONDITION


-----------------------------------------------------------

GET RECEIVE PORT DETAILS BY URL
-----------------------------------------------------------


select
app.nvcName as ApplicationName,

rp.nvcName,

rl.Name,

rl.InboundTransportURL

from bts_applicatin as app

left join dbo.bts_receiveport as rp on rp.nApplicationID = app.nID

left join dbo.adm_ReceiveLocation as rl on rl.ReceivePortId = rp.nID

left join dbo.bts_receiveport_transform as rpt on rpt.nReceivePortID = rp.nID

where rl.InboundTransportURL like 'URL'

-----------------------------------------------------------

GET SEND PORT DETAILS BY APPLICATION
----------------------------------------------------------- 
select

btsApp.nvcName as ApplicationName,

sp.nvcName as SendPortName,

sp.nvcSendPipelineData,

sp.nvcFilter
 from bts_application as btsApp

join bts_sendport as sp on btsApp.nID = sp.nApplicationID

where btsApp.nvcName like '%applicatin name%'




 

Inline xslt example for distinct

Inline Xslt

<xsl:variable name="unique-companies" select="//Employee[not(Company=preceding-sibling::Employee/Company)]/Company" />
<ns0:ListPartners xmlns:ns0="http://MVK.BTS.TECH.OutputFile">
<xsl:for-each select="$unique-companies">
    <PartnerName><xsl:value-of select="."/></PartnerName>
</xsl:for-each>
</ns0:ListPartners>


Source Schema:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://SelectDistinctValues.Input" targetNamespace="http://SelectDistinctValues.Input" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="ExternalEmployees">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" name="Employee">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="Name" type="xs:string" />
              <xs:element name="Company" type="xs:string" />
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>


Destination Schema:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://MVK.BTS.TECH.OutputFile" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://MVK.BTS.TECH.OutputFile" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="ListPartners">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" name="PartnerName" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Introduction to BizTalk Server

Introduction to BizTalk Architecture:

Content based routing:
Message based routing:

What is a zombie? in Biztalk

https://msdn.microsoft.com/en-us/library/bb203853.aspx

Zombies in BizTalk Server

[Unless specifically noted, the content in this topic applies to BizTalk Server 2013 and 2013 R2.]

What is a zombie?

• A zombie message is a message that was routed to a running orchestration from the messagebox and was "in flight" when the orchestration ended. An "in flight" message is a message that has been routed to a service instance and so is in a messagebox queue destined for the service instance. Since the message can no longer be consumed by the subscribing orchestration instance, the message is suspended and marked with a ServiceInstance/State value of "Suspended (Non-resumable)".
  
• A zombie service instance is an instance of an orchestration which has completed while a message that was routed to the orchestration instance from the messagebox was still "in flight". Since the orchestration instance has ended, it cannot consume the "in flight" messages and so is suspended and marked with a ServiceInstance/State value of "Suspended (Non-resumable)".
  

The occurrence of zombies typically falls into one of the following categories:

1. Terminate control messages – The orchestration engine allows the use of control messages to cancel all currently running work in a specific orchestration instance. Since the control message immediately halts the running orchestration, zombie instances are not unexpected. A number of Human Workflow related designs tend to use this mechanism as well as some other designs.
   
2. Parallel listen receives – In this scenario the service instance waits for 1 of n messages and when it receives certain messages it does some work and terminates. If messages are received on a parallel branch just as the service instance is terminating, zombies are created.
   
3. Sequential convoys with non-deterministic endpoints – In this scenario, a master orchestration schedule is designed to handle all messages of a certain type in order to meet some type of system design requirement. These design requirements may include ordered delivery, resource dispenser, and batching. For this scenario, the tendency is to define a while loop surrounding a listen with one branch having a receive and the other having a delay shape followed by some construct which sets some variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered. Non-deterministic endpoints like this are prone to generating zombies.
   

When a zombie service instance is suspended in Microsoft BizTalk Server 2013 R2 the following error message is generated:

BizTalk SQL Queries to find out application artefacts.

bts_application
        Which provides  BizTalk application names which were hosted in the BizTalkApplication reside in BizTalkMgmtDb.


bts_application_reference
         Which contain the BizTalk application reference details reside in BizTalkMgmtDb.


List of BizTalk tables.
http://social.technet.microsoft.com/wiki/contents/articles/22940.biztalkmgmtdb-all-table-details.aspx



SELECT (select nvcName from [bts_application] where nID=appRef.nApplicationID),
         (select app.nvcName where appRef.nReferencedApplicationID=app.nID)
            FROM [BizTalkMgmtDb].[dbo].[bts_application] app
inner join [BizTalkMgmtDb].[dbo].[bts_application_reference] appRef on appRef.[nReferencedApplicationID] = app.nid
where appref.nReferencedApplicationID not in ( '2')


SELECT app.nvcName as ApplicationName,RP.nvcName as ReceivePort, RL.InboundTransportURL FROM [BizTalkMgmtDb].[dbo].bts_receiveport RP
inner join [BizTalkMgmtDb].[dbo].bts_application app on RP.nApplicationID=app.nID
inner join [BizTalkMgmtDb].dbo.adm_ReceiveLocation RL on RP.nID = RL.ReceivePortId
where app.nID not in ('2') and app.nvcName='APPLICATION NAME'


SELECT ItemRef.nvcAssemblyName Artifact_Name, ASS.nvcName Refered_IN, ASS.nvcFullName FullName FROM [BizTalkMgmtDb].[dbo].[bts_itemreference] ItemRef
INNER JOIN [BizTalkMgmtDb].[dbo].[bts_assembly] ASS ON ItemRef.nReferringAssemblyID=ASS.nID
ORDER BY ItemRef.nvcAssemblyName


use BizTalkMgmtDb
 SELECT
app.nvcName as ApplicationName,
SP.nvcName as SendPort,
SPT.nvcAddress AS Address

 FROM [BizTalkMgmtDb].[dbo].bts_sendport SP

inner join [BizTalkMgmtDb].[dbo].bts_application app on SP.nApplicationID=app.nID
inner join [BizTalkMgmtDb].dbo.bts_sendport_transport SPT on SP.nID = SPT.nSendPortID

where app.nID not in ('2') and app.nvcName = 'APPLICATION NAME' and SPT.nvcAddress != ''

HIPPA EDI Introduction.

The Health Insurance Portability and Accountability Act (HIPAA) requires all health insurance payers to comply with the Electronic Data Interchange (EDI) standards for health care as established by the Department of Health and Human Services.


837   --- Claim
835   --- Payment
834   --- Enrolment

276   --- Claim Status Request
277   --- Claim Status Response

270   --- Eligibility Benefit  Request
271   --- Eligibility Benefit  Response

Find out the biztalk applications and it dependants.

SELECT  (select nvcName from [BizTalkMgmtDb].dbo.[bts_application] where nID=appRef.nApplicationID) as MainApplication,
         (select app.nvcName where appRef.nReferencedApplicationID=app.nID) as Dependents
            FROM [BizTalkMgmtDb].[dbo].[bts_application] app
inner join [BizTalkMgmtDb].[dbo].[bts_application_reference] appRef on appRef.[nReferencedApplicationID] = app.nid
where appref.nReferencedApplicationID not in ( '2') order by MainApplication

Introduction to BehaviorExtensionElement

BehaviorExtensionElement

WCF Behaviors are classes that affect runtime operation.

It comes in to the picture when WCF runtime(execution) starts on the client and server       and message flow starts in between the two.

Service Host:

Provides a host for services.

http://blogs.msdn.com/b/justinjsmith/archive/2007/07/02/webservicehost-vs-servicehost.aspx

ServiceHost is responsible for defining the instancing and 
concurrency aspects of a server, in addition to dispatching messages to the 
proper operation.

a) When a message is received by a service and dispatched 
to a certain method of a class,

should ServiceHost  create a new instance 
of that class for each request or should it reuse instances?

b) And when 
ServiceHost  calls the method on that class, should it enlist in a transaction? 
Both of these are specified in behaviors and used during initialization.

There are three primary types of behaviors.

1) Service Behaviors

2) Endpoint Behaviors

3) Operation Behaviors

4) CallBack Behaviors

1) Service behaviors  run at the service level and have access to all of the endpoints. They control items such as instancing and transactions. Service behaviors are also available for authorization and auditing.

2) Endpoint behaviors are scoped to the service endpoint. These are well-suited for inspecting and taking actions on messages as they come in and out of service.

3) Operation behaviors are scoped at the operation level and are well-positioned for manipulating serialization, transaction flow, and parameter handling for a service operation.

4) CallBack Behaviors are similar to the Service Behaviors but control the Endpoints created in duplex communication.