Hvorfor det viktig

Det er svært viktig å holde en god oversikt over ditt miljø etterhvert som det vokser, må du ha et godt grunnlag. Av dette bør du følge gode navnekonvensjoner for programmer, porter, orchestrations og hoster.

Selv om det kan virke om fra starten fordelene med å holde en god navnekonvensjoner for alle applikasjoner vil forbedre brukervennligheten for alle i BizTalk-miljøet, for Microsoft eller andre konsulenter som du kanskje trenger å ansette vil en god navnekonvensjon gjøre det lettere og "bli kjent med ditt miljø". Denne WIKI-artikkelen vil gi deg litt informasjon om hvordan du kan gjør dette, den vil ikke inneholde veiledninger for navnekonvesjoner for andre resurser enn Receive Location, Receive Ports, Orchestration, Send Ports, Send Port groups og Hoster, disse retningslinjene kan være forskjellig fra selskap til selskap. For eksempel så utvikler dere alle applikasjoner "in-house", da kan noen av elementene under ekskluderes. Det er like vel tatt med eksempler slik at dere kan bruke det som passer dere best.

Ved å starte med en god navnekonvensjoner fra første dag vil det være mye lettere når miljøene utvikler seg, samt bringe en bedre overvåking for å sikre at de kritiske "jobbene" er opp og kjører.

Nedenfor er noen eksempler og scenarier forklart for noen forskjellige selskaper.

Navnekonvensjoner

Applikasjoner

Intern utvikling

med mange steder (lager, fabrikken osv.)

Der du har interaksjoner mellom 2 systemer bare
SystemA-SystemB.Location
Eksempel:
ContosoFactory-ContosoStore.USA

Der kommunikasjon er fra eller til ett system men distribuert til mange systemer
IntegrationName.Location
Eksempel
ContosoUpdatingWarehouse.USA

Merk: Plasseringen er valgfri

Utvikling av interne og eksterne

med mange steder (lager, fabrikken osv.)

Der du har interaksjoner mellom 2 systemer bare
CreatedBy.SystemA-SystemB.Location
Eksempel:
Microsoft.ContosoFactory-ContosoStore.USA

Der kommunikasjon er fra eller til ett system men distribuert til mange systemer
CreatedBy.IntegrationName.Location
Eksempel
Microsoft.ContosoUpdatingWarehouse.USA

Merk: Plasseringen er valgfri

Mottak (Receive Locations og Receive Ports), sende porter (grupper) og Orchestrations

Framework:
TypeOfPort.ToOrFrom/Purpose.Location
Eksempel:

Receive Port
RcvPrt.ContosoFactory.USA

Reveice Location
RcvLoc.ContosoFactory.NY

Send Port-gruppen
SndGrp.ContosoWarehouse.Europe

Send-Port
SendPrt.ContosoWarehouse.Norway

Orchestration
Orc.TransformOrderToUodateInv.Global

Hosts

Når det gjelder hoster er det litt opp til hver enkel, det kommer også an på hvor kompleks systemet er hos dere, noen selskaper har ikke så mange applikasjoner, og ofte deles hoster for hver applikasjon, noen har for mange applikasjoner og må opprette mange hoster samtidig for å gjøre arbeidet. Denne veiledningen dimensjonert for et stort selskap med mange applikasjoner.

<Job> _ < biters støtte > _ <seq> _ < kort/funksjonalitet > _ <throughput> _ <priority> _ <clustered>

Eksempler
Dette er en mottak host, med x32 OS, sekvensnummer 1, denne hosten bare kjører FTP-adapteret, det er innstilt for raskt svar og er klustret. Det er også merket som kritisk
Rcv_x32_1_FTP_L_Critical_Clustered

Dette er en sending host, x64 OS, dette er det andre adapteret med denne konfigurasjonen (sekvensnummer 2) og kjører mange ulike adaptere, den er innstilt for høy ytelse, den er ikke merket som kritisk, og er ikke klustret
Snd_x64_2_Random_H_None_None

Dette er en 64-bits orchestration host, det er dimensjonert for høy ytelse og er merket som foretningskritisk.
Orch_x64_H_Critical

Andre språk

Denne artikkelen er også tilgjengelig på følgende språk

• Engelsk: BizTalk Naming Convention