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.
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
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
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
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
Denne artikkelen er også tilgjengelig på følgende språk
Carsten Siemens edited Revision 5. Comment: Added tag: has TOC
Tord G.Nordahl edited Revision 4. Comment: added reference to original article
Ed Price - MSFT edited Revision 2. Comment: Added the tag. Please link back to the original article when you can. This is a great example of translating your own articles! You get twice the value!
Tord G.Nordahl edited Revision 1. Comment: removed some text that shouldnt be there