Ganske ofte i arbeidet med store bedrifter og butikkjeder det er behov for datautveksling mellom databaser. Hver programmerer og administrator løser dette problemet forskjellig. Noen skriver opplasting-nedlastinger gjennom mellomtabellfiler, noen bruker modusen COM-tilkoblinger for å koble til basekilden. Imidlertid, i i det siste sin egen 1C-ovsky-mekanisme kalt " Universell utveksling data i XML-format ".
Behandler utseende
I Full-grensesnittet kan du åpne behandlingen på Service-> Andre datautvekslinger-> Universell datautveksling i XML-format.
Behandlingsskjemaet (fig. 1) inneholder fire faner:
Grensesnittet til hver av fanene er tungt lastet med elementer, og krever derfor separat vurdering.
Laster opp data
Helt øverst i bokmerket er det et felt for valg av en utvekslingsreglerfil. For ikke-standardiserte baser og utvekslinger, må du opprette utvekslingsfilen selv.
På neste linje skjemaer, er det to alternativknapper:
- Opplasting til en utvekslingsfil (fig. 2);
- Koble til og laste opp data til IS (fig. 3).
Som du kan se fra bildene ovenfor, avhengig av bryteren utseende skjemaer. Hvis alternativet for filutveksling er valgt, blir brukeren bedt om å velge plasseringen til filen der opplastingen skal utføres og muligheten for å komprimere den for å spare plass og beskytte den med et passord.
Alternativ direkte kontakt til mottakerbasen støtter den både fil- og klient-serverdrift. I dette tilfellet vil det være nødvendig å registrere adressen til basen, fyll ut feltene "Bruker" og "Passord". Før du fortsetter med utveksling av data, er det tilrådelig å teste tilkoblingen.
Tabelldel som ligger under lar deg konfigurere ekstraksjoner og andre losseparametere.
For å feilsøke algoritmer og fikse feil kan du bruke mekanismen som er innebygd i utvekslingsbehandlingen. Aktiveringen utføres ved å merke av i den tilsvarende avmerkingsboksen nederst i skjemaet. Ved å trykke på "Debug settings ..."-knappen åpnes vinduet (fig. 4).
Fig. 4
Særpreget trekk dette skjemaet er en informativ hjelp på venstre side av oppsettet som beskriver hver av de tre mulige moduser feilsøking. Som en fil ekstern behandling enhver epf-fil kan brukes med modulen.
Ved å klikke på "Fullfør"-knappen kontrolleres riktigheten og fullstendigheten av de utfylte dataene.
I motsetning til "Last opp", har ikke denne fanen (fig. 5) en tabelldel, men det er mange flere flagg som lar deg justere parametrene for å registrere nye og endrede objekter.
Fig. 5
Først av alt, må du velge en fil som vil tjene som en kilde til informasjon. Dette kan gjøres i inntastingsfeltet "Last ned filnavn". Hvis dataene ble lastet opp til et passordbeskyttet arkiv, må de legges inn i det aktuelle feltet.
De tilsvarende avmerkingsboksene lar deg konfigurere:
- Transaksjon ved skriving av objekter (dette setter noen ganger fart på prosessen);
- Lasting av data i utvekslingsmodus (i dette tilfellet vil alle plattformkontroller, med unntak av kontroller under dokumenter, bli ignorert ved opptak);
- Overskrive endrede elementer;
- Installere slettemerker for nedlastede elementer;
- Modusen for å skrive nye data til registeret (enten en etter en eller ved å ringe);
- Trimming av ubetydelige tegn (mellomrom og tabulatorer) for strengverdier.
Tilleggsinnstillinger
Som navnet på bokmerket tilsier, inneholder det verktøy, hvis bruk lar deg finjustere utvekslingsprosessen. Spesielt:
- Slår på feilsøkingsmodus;
- Lar deg bruke en transaksjon i opplastingsprosessen;
- Optimaliserer utvekslingen mellom databaser av den åttende versjonen av 1C;
- Loss kun de objektene som er tillatt å brukes nåværende bruker;
- Aktiver logging av utvekslingsprosessen mellom databaser.
Disse og noen andre funksjoner aktiveres ved å sette de riktige avmerkingsboksene på skjemaet (fig. 6).
Fig. 6
Sletter data
Denne kategorien brukes kun av utviklere i feilsøkingsmodus. Lar deg fjerne unødvendige objekter fra databasen.
Kort om å sette utvekslingsregler
Å bruke en standard behandler gjør livet mye enklere for programmerere. Samtidig er et av de vanskeligste øyeblikkene for noen som først møtte Universal Data Exchange i XML-format spørsmålet: "Hvor kan jeg få tak i filen med utvekslingsregler?".
Først av alt, for selvlaget utvekslingsregler, kreves en spesiell konfigurasjon, som kalles "Datakonvertering". Det inkluderer flere interessante filer, som lar deg konfigurere nesten hvilken som helst utveksling mellom forskjellige baser 1C 7 og 8 versjoner:
- epf - nødvendig for å laste ut metadatastrukturen for 1C 8-databaser;
- epf - hvis 1C 8-konfigurasjonen er selvskrevet eller ikke standard, kan det hende at den ikke har Universal Data Exchange-behandling, denne filen er denne behandlingen;
- ert - filen inneholder koden for å laste ut til 1C versjoner 7.7;
- ert - fil for behandling av dataavlasting og lasting for de syv.
Etter å ha startet den riktige behandlingen, er det nødvendig å avlaste metadatastrukturene for kildebasen og mottakerbasen. Deretter, i "Konvertering"-konfigurasjonen, er det nødvendig å legge inn informasjon om kilde- og mottakerkonfigurasjonene i "Konfigurasjoner"-katalogen.
Deretter opprettes et element i konverteringskatalogen som inneholder informasjon om retningen for datautveksling. Du kan sette opp utvekslingsreglene for det.
Behandling av "Universell datautveksling i XML-format" er ment for å laste og losse data til en fil fra en hvilken som helst konfigurasjon implementert på 1C: Enterprise 8-plattformen
Behandlingen har fire faner
Laster opp data
For å laste ut data må du spesifisere navnet på filen som dataene skal lastes ut i, og velge filen med utvekslingsregler. Utvekslingsregler for alle konfigurasjoner kan konfigureres i den spesialiserte konfigurasjonen "Datakonvertering, utgave 2".
For å laste opp dokumenter og registreringer av uavhengige periodiske registre over informasjon, må du spesifisere perioden - "Startdato" og "Sluttdato". Den resulterende filen med de opplastede dataene kan komprimeres.
På fanen "Regler for datautlasting" kan du velge hvilke typer objekter som skal avlastes, sette opp filtre for å velge objekter, eller spesifisere datautvekslingsnoden du vil laste ut data for.
På fanen "Last opp parametre" kan du spesifisere Ekstra alternativer lossing av data.
På "Kommentar"-fanen kan du skrive en vilkårlig kommentartekst som skal inkluderes i utvekslingsfilen.
For å laste data må du spesifisere navnet på filen som dataene skal lastes fra.
Det er mulig å tilpasse lasting av data til en transaksjon. For å gjøre dette, merk av for "Bruk transaksjoner" og spesifiser antall varer i en transaksjon ved lasting.
Tilleggsinnstillinger
Bokmerket brukes til finjustering laste opp og laste ned data.
"Debug mode" - avkrysningsboksen bestemmer modusen for lossing og lasting av data
"Antall behandlede objekter for å oppdatere statusen" - parameteren brukes til å bestemme antall behandlede varer før du endrer linjestatus for lasting / lossing
"Dataopplastingsinnstillinger" - lar deg bestemme antall elementer behandlet i en transaksjon når du laster opp data, last opp og behandle bare de objektene du har tilgangsrettigheter til, konfigurer type registreringsendring for lossede objekter gjennom utvekslingsplaner
"Utvekslingsprotokoll" - lar deg tilpasse utgangen informasjonsmeldinger til meldingsvinduet, vedlikeholde og skrive til egen fil utvekslingsprotokoll.
Sletter data
Bokmerket er kun nødvendig for utviklere av utvekslingsregler. Lar deg fjerne fra informasjonsgrunnlag vilkårlige objekter.
Feilsøking av dataopplasting og nedlasting
Behandling lar deg feilsøke hendelsesbehandlere og generere en feilsøkingsmodul fra en regelfil eller datafil.
Aktivering av feilsøkingsmodus for lossebehandlere utføres på fanen "Datalossing" ved å sette avkrysningsboksen "Debugging lossing handlers". Følgelig, på "Data loading"-fanen, aktiveres lasting av feilsøkingsmodus ved å sette av for "Load handlers debugging mode".
Etter å ha angitt feilsøkingsmodusen til behandlerne, vil knappen for feilsøkingsinnstillinger bli tilgjengelig. Ved å klikke på denne knappen åpnes innstillingsvinduet.
Feilsøkingsbehandlere konfigureres i fire trinn:
Trinn 1: Velge algoritmefeilsøkingsmodus
I det første trinnet må du bestemme modusen for feilsøkingsalgoritmer:
Uten feilsøkingsalgoritmer
Anropsalgoritmer som prosedyrer
Erstatt algoritmekode på anropsstedet
Den første modusen er praktisk å bruke når vi vet med sikkerhet at feilen i behandleren ikke er relatert til koden til noen algoritme. I denne modusen blir ikke algoritmekoden dumpet inn i feilsøkingsmodulen. Algoritmene kjøres i sammenheng med "Run ()"-setningen og koden deres er ikke tilgjengelig for feilsøking.
Den andre modusen må brukes i tilfeller der feilen er i koden til algoritmen. Når denne modusen er satt, vil algoritmene bli lastet ut som separate prosedyrer. I det øyeblikket algoritmen kalles fra en hvilken som helst behandler, kalles den tilsvarende behandlingsprosedyren. Denne modusen er praktisk å bruke når den globale variabelen "Parameters" brukes til å sende parametere til algoritmer. Begrensningen ved å bruke denne modusen er at de lokale variablene til behandleren som den kalles fra, ikke er tilgjengelige i algoritmen under feilsøking.
Den tredje feilsøkingsmodusen brukes, som i det andre tilfellet, ved feilsøking av algoritmekoden og i de tilfellene der den andre feilsøkingsmodusen ikke er egnet. Når denne modusen er satt, vil algoritmer bli lastet ut som integrert kode i behandlere. De. i stedet for algoritmen er anropsoperatøren satt inn full kode algoritme som tar hensyn til nestede algoritmer. I denne modusen er det ingen restriksjoner på bruken av lokale behandlervariabler, men det er en begrensning ved feilsøking rekursivt kalt algoritmer.
Trinn 2: Bygg feilsøkingsmodulen
På det andre trinnet må du losse behandlerne ved å klikke på knappen "Generer lossing (lasting) feilsøkingsmodul". De genererte behandlerne og algoritmene vil vises i eget vinduå se. Innholdet i feilsøkingsmodulen må kopieres til utklippstavlen ved å klikke på knappen "Kopier til utklippstavlen".
Trinn 3: Opprett ekstern behandling
På dette trinnet må du starte konfiguratoren og opprette en ny ekstern behandling. I behandlingsmodulen må du lime inn innholdet på utklippstavlen (feilsøkingsmodul) og lagre behandlingen under et hvilket som helst navn.
Trinn 4: Koble til ekstern prosessering
På det fjerde siste trinnet må du angi navnet på den eksterne behandlingsfilen i inndatafeltet. I dette tilfellet sjekker programmet ved opprettelse (oppdatering) av behandlingsfilen. Hvis behandlingen har mer tidlig versjon enn versjonen av feilsøkingsmodulfilen, vil en advarsel vises og konfigurasjonsskjemaet vil ikke bli lukket.
Merk: Muligheten til å feilsøke den globale konverteringsbehandleren "Etter lasting av utvekslingsreglene" støttes ikke.
Automatiserte systemer forvaltningen består i de fleste tilfeller av separate databaser og har ofte en geografisk fordelt struktur. I dette tilfellet, en korrekt implementert datautveksling - nødvendig tilstand til effektivt arbeid slike systemer.
Samtidig kan det innledende utvekslingsoppsettet kreve en rekke handlinger, ikke bare når det gjelder programmering, men også rådgivning, selv om vi har å gjøre med homogene kilder, slik tilfellet er med produkter på 1C: Enterprise-plattformen. Hvorfor det å sette opp 1C-sentral (eller, som det også kalles, datasynkronisering i 1C 8.3) kan bli den mest tidkrevende og kostbare oppgaven i et integrasjonsprosjekt, skal vi vurdere i denne artikkelen.
Datautveksling i 1C-miljøet tillater:
- Eliminer dobbeltregistrering av dokumenter;
- Automatiser relaterte forretningsprosesser;
- Optimaliser kommunikasjonen mellom distribuerte enheter;
- Oppdater dataene raskt for arbeidet til spesialister fra forskjellige avdelinger;
- "avgrense" forskjellige typer regnskap. *
* I tilfellet når dataene til en type regnskap skiller seg vesentlig fra en annen, er det nødvendig å sikre konfidensialitet av informasjon og "avgrense" informasjonsflyt. For eksempel krever utveksling av data mellom 1C UT og 1C Accounting ikke opplasting av styringsdata til den rutinemessige regnskapsdatabasen, dvs. synkronisering i 1C vil være ufullstendig her.
Hvis du forestiller deg standard prosess implementering av primær datautveksling, når minst ett av objektene er et 1C-produkt, kan følgende stadier skilles:
- Koordinering av sammensetningen av utvekslingen;
- Definisjon av transport (utvekslingsprotokoller);
- Sette regler;
- Planlegging.
Avsløre sammensetningen av utveksling 1C
Utvekslingsobjektene kan betinget deles inn i "kilde" og "mottaker". Dessuten kan de utføre to roller samtidig, som vil bli kalt - bilateral utveksling. Bestemmelse av kilde og destinasjon skjer på en logisk måte, avhengig av behov eller på funksjonalitet system. *
* For eksempel ved integrering av "WA: Financier" - løsninger for vedlikehold finansregnskap og styring av treasury-prosesser, utviklet på grunnlag av 1C: Enterprise, WiseAdvice-eksperter anbefaler det som et hovedsystem. Dette skyldes tilgjengeligheten av kontrollverktøy for å overholde reglene i applikasjonspolicyen, og følgelig for å sikre effektiviteten til løsningen.
Videre, basert på de mottatte og registrerte kravene fra brukerne, opprettes en liste over data for utveksling, deres volum, kravene til utvekslingsfrekvensen bestemmes, prosessen med å jobbe med feil og behandling av eksepsjonelle situasjoner (kollisjoner) er foreskrevet.
På samme stadium, avhengig av flåten av eksisterende systemer og strukturen til bedriften, bestemmes utvekslingsformatet:
Distribuert informasjonsgrunnlag
- RIB innebærer utveksling mellom identiske konfigurasjoner av 1C-databaser, med en klar master-slave-kontrollstruktur for hvert utvekslingspar. Som et element i den teknologiske plattformen kan RIB, i tillegg til data, overføre endringer i konfigurasjonen og administrativ informasjon til databasen (men bare fra master til underordnet).
Universell datautveksling i 1C
- En mekanisme som lar deg konfigurere utveksling av 1C-databaser, både med konfigurasjoner på 1C: Enterprise-plattformen, og med tredjeparts utviklingssystemer. Utvekslingen utføres ved å overføre data til universelt xml-format i henhold til "Utvekslingsplanene".
EnterpriseData
- Den siste utviklingen av 1C, designet for å implementere datautveksling i xml-format mellom produkter laget på 1C: Enterprise-plattformen med alle automasjonssystemer. Bruk av EnterpriseData forenkler utvekslingsrelaterte forbedringer. Tidligere når du er logget inn i systemet ny konfigurasjon det var nødvendig å implementere en mekanisme for import og eksport av data, både for den og for eksisterende systemer. Nå trenger ikke systemer som støtter EnterpriseData noen modifikasjoner, de har bare ett "entry-exit"-punkt.
Definisjon av transport (utvekslingsprotokoller)
For systemet basert på 1C: Enterprise 8-plattformen er det gitt et bredt spekter av muligheter for å organisere en utveksling med evt. informasjonsressurser gjennom allment aksepterte universelle standarder (xml, tekstfiler, Excel, ADO-tilkobling, etc.). Derfor, når man definerer en transport for utveksling av data, bør man gå ut fra mulighetene til en tredjeparts systemdatabase.
Synkronisering av kataloger
Hovedprinsippet for effektiv synkronisering av kataloger er tilstedeværelsen av ett inngangspunkt. Men hvis det kommer for å arbeide med oppslagsverk som historisk ble fylt ut i henhold til forskjellige regler, er det nødvendig å tydelig definere synkroniseringsfeltene for å bringe utvekslingen til en "fellesnevner". *
* På dette stadiet kan det være nødvendig å utføre arbeid med normalisering av referansedataene på siden av datakilden. Avhengig av tilstanden til oppslagsbøkene og deres størrelse, kan prosessen med å matche elementer, gjenkjenne, oppdage feil og duplikater, samt fylle ut manglende felt og tildele synkroniseringsfelt, kreve arbeid fra en hel gruppe eksperter, både fra integratoren (eier av standardiseringsmetoden for referansedata) og fra kundens side.
Sette regler
Muligheten til å vise data fra kildesystemer i mottakere avhenger av korrekt spesifiserte utvekslingsregler. Reglene, presentert i xml-formatet, regulerer samsvaret med nøkkelattributtene til kildedestinasjonsobjektene. 1C: Data Conversion-løsningen er designet for å automatisere opprettelsen av regler for implementering av både en engangsutveksling og en permanent.
Sikrer ikke tap av data ved utveksling av Exchange Plan. den komponent enhver konfigurasjon på 1C: Enterprise-plattformen, som fullt ut beskriver prosedyren for utveksling av 1C: datasammensetning (dokumenter med "identifikasjon"-detaljer) og noder (informasjonsbaser for mottakere og sendere), samt RIB-aktivering for utvalgte utvekslingsretninger.
Enhver endring i dataene som er lagt inn i utvekslingsplanen blir registrert og får et tegn på "endring". Inntil de endrede dataene samsvarer med hverandre i sender-mottaker-nodene, vil ikke flagget bli slettet, og systemet vil sende kontrollmeldinger til begge nodene. Etter å ha lastet ut dataene og bekreftet deres fulle korrespondanse i begge systemene, tilbakestilles skiltet.
Utvekslingsplan i 1C
For å automatisere den vanlige utvekslingen, er frekvensen for dataopplasting satt. Utvekslingsfrekvensen avhenger av behovet og tekniske evner... Også konfigurasjoner på 1C: Enterprise-plattformen lar deg sette opp datautveksling når en hendelse inntreffer.
Etter å ha vurdertgsprosessen, la oss ta hensyn til faktorene som vil kreve forbedringer på forskjellige stadier:
- Ikke-typiske, svært modifiserte databasekonfigurasjoner;
- Ulike versjoner av 1C: Enterprise-plattformen;
- Ikke oppdatert på lenge, ikke gjeldende versjoner konfigurasjon;
- Utvekslingsobjekter som tidligere har gjennomgått modifikasjoner;
- Behovet for ikke-standard utvekslingsregler;
- Et helt annet sett og sammensetning av rekvisita i de tilgjengelige oppslagsbøkene.
Siden enda standard handlinger på implementeringen av den primære datautvekslingen krever ekspertkunnskap, det anbefales å utføre det med deltakelse av 1C-spesialister. Først etter å ha fullført alle trinnene ovenfor, bør du fortsette med å sette opp sentralen i konfigurasjonen. La oss vurdere integrasjonen av databaser ved å bruke eksemplet "1C: UPP" og "1C: Retail" (i henhold til samme skjema er utveksling med "1C: UT" konfigurert). Den typiske synkroniseringen inkluderer også utveksling av SCP - SCP, som er typisk for storskala automasjonssystemer i de største industribedriftene.
I undermenyen "Service" velger du "Datautveksling med produkter på plattformen ..." (valget av direkte utveksling med "Detaljhandel" truer ofte med feil på COM-objektnivå). Følg med på tjenestemelding « Denne sjansen utilgjengelig."
For å løse dette problemet må du velge "Kommunikasjonsinnstillinger"
... og kryss av i boksen. Deretter ignorerer vi feilmeldingen.
I innstillingene for datasynkronisering velger du "Opprett en utveksling med" Retail "...
Før du konfigurerer tilkoblingsinnstillinger via lokal eller nettverkskatalog du bør sørge for at det er plass til katalogen på disken. Selv om det som regel ikke tar mer enn 30-50 MB, kan det i unntakstilfeller kreve opptil 600 MB. Du kan opprette ønsket katalog direkte fra konfiguratoren.
Ved tilkobling via en nettverkskatalog tilbyr tilbudet å konfigurere tilkoblingen via en FTP-adresse og via e-post ignorert ved å klikke "Neste".
I innstillingene legger du ned prefiksene manuelt - legende baser (som regel BP, UPP, RO), angi reglene og startdatoen for dataopplasting. Prefikset vil bli angitt i navnet på dokumentene for å indikere basen de ble opprettet i. Hvis utlastingsreglene ikke er redigert, vil dataene bli lastet ut som standard for alle tilgjengelige parametere.
Vi oppretter en utvekslingsinnstillingsfil for "Detaljhandel" for ikke å gjenta handlingene våre. Hvis du trenger å sende data umiddelbart etter at du har satt opp synkronisering, merk av i boksen.
For å automatisere utvekslingsprosessen må du sette opp en tidsplan.
Detaljhandelsmeny.
Merk av i boksen og velg "Synkronisering".
Vi gjør den "omvendte" innstillingen ved å velge Manufacturing Enterprise Management.
Last inn innstillingsfilen som er opprettet i SCP.
Vi setter et hake, systemet henter adressen automatisk.
Vi opptrer på samme måte som i SCP.
Verifikasjonsdatasammenligning (Manuell datasammenligning anbefales på det forberedende stadiet, siden dette arbeidet kan bli det mest tidkrevende i prosessen med å implementere utvekslingen). Kartvinduet åpnes av Dobbeltklikk mus.
Ved feil i synkroniseringen vil "Detaljer ..." bli erstattet med "Aldri ...".
"I detalj ..." åpner en registreringslogg med oppdatert informasjon om børsen.
Klar.
| Parameternavn | Betydning |
| Tema for artikkelen: | XML-datautveksling |
| Kategori (tematisk kategori) | teknologier |
DBMS kan støtte utveksling av XML-data på en veldig enkel måte – støtte utdata av spørringsresultater og inndata for INSERT-setningen i XML-format. Dette krever imidlertid at brukeren eller programmereren nøye vurderer formatet til de genererte spørringsresultatene slik at det samsvarer nøyaktig med formatet til INSERT-setningen i mottaksdatabasen. Utveksling XML-data bør være veldig nyttig hvis det er mer eksplisitt støttet av DBMS.
Flere kommersielle produkter tilby muligheten batch eksport tabeller (eller søkeresultater) i ekstern fil formatert som XML-dokument. Imidlertid tilbyr de en lignende mulighet til å batchimportere data fra en fil av samme type til en DBMS-tabell. Dette skjemaet lager XML standard format presentasjon av innholdet i tabeller for datautveksling.
Vær oppmerksom på at bruken av mulighetene for import/eksport av tabelldata i XML-format som tilbys av DBMS ikke begrenser deres bruk for utveksling mellom databaser.
Datautveksling i XML-format - konsept og typer. Klassifisering og funksjoner i kategorien "Datautveksling i XML-format" 2017, 2018.
XML Markup Language Markup Languages Merket tekst gjør det enkelt å analysere og manipulere tekst. Det inkluderer: · tekst som bærer semantisk informasjon (infosett); · Markup, som indikerer strukturen til teksten. Markup language er laget for å ...
Den første versjonen av språket hypertekstmarkering- HTML (HyperText Markup Language), så vel som seg selv Webteknologi ble utviklet av Tim Berners Lee i 1991. HTML er en SGML-applikasjon for en type dokument som har fått navnet HTML-dokumenter... Språket definerer en fast struktur, ....
XML (Extensible Markup Language) er et markup-språk som beskriver en klasse med dataobjekter kalt XML-dokumenter. XML-språket brukes som et middel for å beskrive grammatikken til andre språk og kontroll over riktigheten av dokumenter / 6 /. I motsetning til HTML XML-språk tillater 1.....
Struktur XML-dokument inkluderer overskrift, DOCTYPE-seksjon, XML-dokumenttekst. Tittelen beskriver versjonen og kodingen. DOCTYPE-delen beskriver enheter. Entitet er en konstant som brukes i hoveddelen av et XML-dokument for stenografi og vedlikehold. I XML-kroppen ...
Definerer en behandler for hendelsen som oppstår hver gang tilstanden til objektet endres. Navnet må skrives med små bokstaver. ReadyState eiendom XMLHttpRequest-objekt... ReadyState-egenskapen definerer Nåværende tilstand XMLHttpRequest-objekt. Tabellen viser mulige verdier....
Definerer en behandler for hendelsen som oppstår hver gang tilstanden til objektet endres. Navnet må skrives med små bokstaver. ReadyState-egenskapen til XMLHttpRequest-objektet. ReadyState-egenskapen bestemmer gjeldende tilstand for XMLHttpRequest-objektet. Tabellen viser mulige verdier...
V i fjor W3C (WWW Consorcium) jobber aktivt med å radikalt revidere grunnlaget for nettteknologi. Som et resultat ble Extensible Markup Language (XML) opprettet for å beskrive og behandle informasjon ...
Skriv ut (Ctrl + P)
Utveksling via et universelt format
Undersystemet "Datautveksling" til biblioteket med standard delsystemer inneholder 4 alternativer (teknologier) for utveksling av informasjon mellom ulike informasjonsbaser:
- distribuerte informasjonsbaser (RIB);
- datautveksling via universelt format;
- datautveksling i henhold til utvekslingsregler (utvekslingsregler opprettes ved å bruke "Datakonvertering"-konfigurasjonen, versjon 2.1);
- datautveksling uten utvekslingsregler.
Denne artikkelen diskuterer teknologien for å utveksle data gjennom generisk EnterpriseData-format. Denne teknologien tilgjengelig i "Library of standard subsystems" fra og med versjon 2.3.1.62. utgitt tidlig i 2016. På dette øyeblikket, siste revisjon BSP 2.3 (for bruk med 1C: Enterprise 8.3-plattformen som ikke er lavere enn versjon 8.3.8.1652 med deaktivert kompatibilitetsmodus) har utgivelse 2.3.6.17.
Ris. 1 Siste utgivelser BSP 2.3
Blant leveringsfilene til 1C anvendte løsninger er det tekstfil“Versjoner av biblioteker”, hvor applikasjonen ble utviklet på bakgrunn av hvilken BSP-versjon, for eksempel basert på applikasjonsløsningen UT 11.3.3.231, BSP 2.3.5.65 som ble lagt.
Merk at for bruk med plattformen "1C: Enterprise 8.3" versjon ikke lavere enn 8.3.10.2168 med deaktivert kompatibilitetsmodus utgitt BSP 2.4.
EnterpriseData-formatbeskrivelse
Hva er EnterpriseData-format?
Dette er et format som lar deg beskrive et infobaseobjekt (motpart, faktura osv.) eller rapportere at dette objektet er slettet. Det forventes at konfigurasjonen som mottok filen i EnterpriseData-formatet vil reagere deretter – den vil lage nye objekter i seg selv og slette de som er merket som slettet i filen. Den er beregnet for informasjonsutveksling mellom konfigurasjoner av UT, RT, UNF, BP. Formatet kan også brukes til å utveksle informasjon med andre informasjonssystemer: det avhenger ikke av sine egne egenskaper programvare eller infobasestrukturer som deltar i utvekslingen og ikke inneholder eksplisitte restriksjoner på bruk.
EnterpriseData-formatversjon
Formatdata lagres i XDTO - pakker i en filial generelle konfigurasjoner database, som vist i fig. 2
Fig. 2 XDTO - EnterpriseData-dataformatpakker I fig. Figur 2 viser at det er flere XDTO-pakker. den forskjellige versjoner format. Formatversjonsnummeret består av X.Y.Z, der X.Y er versjonen og Z er Minor-versjonen. Mindre versjon økes i tilfelle feilretting og andre endringer, der: ytelsen til datakonverteringslogikken basert på forrige versjon format (lagrer bakoverkompatibilitet gjeldende algoritmer for overføring av data gjennom formatet); Støtte for nye formatfunksjoner for konverteringslogikk er frivillig. Et eksempel på slike endringer kan være å fikse en feil, endre egenskapene til formatobjekter, legge til egenskaper, bruken av disse er valgfri ved konvertering av data. I andre tilfeller, når formatet endres, økes Major-versjonen: X - ved en global restrukturering, Y - i andre tilfeller.
Formatet beskriver presentasjonen av objekter (dokumenter eller katalogelementer) i form av XML-filer. Versjon 1.0.1 inneholder beskrivelser av 94 objekter fra ulike områder(finans, produksjon, kjøp og salg, lagerdrift). Typenavnene er vanligvis godt forstått og trenger ikke ytterligere forklaringer: for eksempel "Document.Act of CompletedWorks" eller "Directory.Contractors". Som du kan se, begynner beskrivelsen av dokumenttyper med prefikset "Dokument.", Et katalogelement - med prefikset "Katalog.". Mer formatbeskrivelse finner du
Den siste versjonen er 1.3, men den mest brukte versjonen er 1.0. Nei stor forskjell mellom versjoner. Format EnterpriseDataExchange_1_0_1_1
brukes ved utveksling via en nettjeneste.
Merk, at pakken brukes med EnterpriseData-dataformatpakken ExchangeMessage når du oppretter konverteringsregler. Det er denne pakken som inneholder typeobjektet Tilleggsinformasjon,som kan være av hvilken som helst verditype og brukes når du oppretter en regel for konvertering mellom konfigurasjonsobjekter. som mangler i dataformatet. Nemlig takket være Tilleggsinformasjon,du kan tilpasse og tilpasse utvekslingsreglene uten å endre formatdataene i XDTO-pakker.
Hvordan utveksle data i EnterpriseData-format?
EnterpriseData-datautveksling med konfigurasjon er en filutveksling. Som svar på mottatt fra ekstern applikasjon konfigurasjonsfilen vil behandle den og lage en svarfil. Filutveksling kan forekomme:
- gjennom en dedikert filkatalog,
- via FTP-katalogen,
- via en nettjeneste utplassert på infobasesiden. Datafilen sendes som en parameter til webmetodene.
Merk... For toveis datautveksling mellom en tredjepartsapplikasjon og konfigurasjonen må det gjøres en rekke innstillinger på infobasesiden - tredjepartsapplikasjonen må være registrert i infobasen, det må defineres en utvekslingskanal for den (via en fil eller FTP-katalog), etc. Men for tilfeller av enkel integrasjon, når det er nok bare å overføre informasjon fra tredjepartsapplikasjon til infobasen og ingen returoverføring av data fra infobasen til en tredjepartsapplikasjon kreves (for eksempel integrasjon av en nettbutikk som overfører informasjon om salg til 1C: Accounting), er det en forenklet versjon av arbeidet gjennom en nettjeneste som ikke krever eksterne innstillinger.
Ved utveksling med utvekslingsplaner overfører konfigurasjoner under synkronisering kun informasjon om endringer som har skjedd siden siste synkronisering (for å minimere volumet overført informasjon). Ved den første synkroniseringen vil konfigurasjonen laste opp alle EnterpriseData-objekter til en XML-fil (siden de alle er "nye" for tredjepartsapplikasjonen).
Det neste trinnet er for en tredjepartsapplikasjon - den må behandle informasjonen fra XML-filen og, under neste synkroniseringsøkt, plassere den i seksjonen
Ved mottak av kvitteringsmeldingen, merker konfigurasjonen alle endringer som er sendt inn i forrige melding som vellykket synkronisert. Kun usynkroniserte endringer av objekter (opprette nye, endre og slette eksisterende) vil bli sendt til den eksterne applikasjonen under neste synkroniseringsøkt.
Når data overføres fra en ekstern applikasjon til konfigurasjonen, blir bildet reversert. Søknaden må fylle ut avsnittet
Etter å ha behandlet filen vil konfigurasjonen generere en XML-fil som vil inneholde en kvitteringsmelding og nye data for synkronisering fra konfigurasjonssiden (hvis noen siden siste synkroniseringsøkt).
Lær mer om å kommunisere med anvendte løsninger på 1C: Enterprise-plattformen i EnterpriseData-formatet, kan du se
Generell modul "utvekslingsansvarlig gjennom universelt format".
Prosedyrer og funksjoner som fullt ut beskriver reglene for utlasting av data fra en infobase til et utvekslingsformat og reglene for innlasting av data fra et utvekslingsformat til en infobase er utviklet i en felles modul - en utvekslingsansvarlig modul gjennom et universelt format.
Ris. 4 Strukturen til utvekslingsledermodulen gjennom et universelt format Modulen opprettes automatisk ved å bruke "Datakonvertering"-konfigurasjonen, revisjon 3.0, basert på de konfigurerte utvekslingsreglene, eller manuelt i konfiguratoren.
Modulen består av flere store seksjoner som hver inneholder sin egen gruppe av prosedyrer og funksjoner.
- En kommentar. Den første linjen i modulen inneholder en kommentar med navnet på konverteringen. Denne linjen er nødvendig for å identifisere modulen når du bruker kommandoen i programmet "Datakonvertering", revisjon 3.0., For eksempel. // Konvertering av UP2.2.3 datert 06.01.2017 19:51:50
- Konverteringsprosedyrer... Inneholder forhåndsdefinerte prosedyrer som utføres på forskjellige stadier av datasynkronisering: før konvertering, etter konvertering, før utsatt fylling.
- Databehandlingsregler (POD)... Inneholder prosedyrer og funksjoner som beskriver databehandlingsregler.
- Regler for objektkonvertering (OCP)... Inneholder prosedyrer og funksjoner som beskriver reglene for konvertering av objekter, samt regler for konvertering av egenskaper til disse objektene.
- Forhåndsdefinerte regler for datakonvertering (PKPD). Inneholder en prosedyre som fyller ut reglene for konvertering av forhåndsdefinerte data.
- Algoritmer... Inneholder vilkårlige algoritmer som kalles fra andre regler (POD eller PKO).
- Alternativer. Inneholder logikken for å fylle ut konverteringsparametrene.
- Generelt formål... Inneholder prosedyrer og funksjoner som er mye brukt i regler og algoritmer.
Parametrene for prosedyrer og funksjoner som brukes i flere typer prosedyrer i ledermodulen er beskrevet nedenfor.
Komponentutveksling. Type - Struktur... Inneholder parametere og utvekslingsregler, initialisert under utførelsen av utvekslingsøkten.
Retning av utveksling. Type - String... Enten sender eller mottar.
IB-data. Type - DirectoryObject eller DocumentObject.
Prosedyrer for konverteringshendelser
Det er tre forhåndsdefinerte prosedyrer som kalles under konverteringsprosessen:
- Før konvertering... Ringes før datasynkronisering utføres. Vanligvis inneholder denne rutinen initialiseringslogikken ulike parametere konvertering, utfylling av standardverdier osv. Parametere: Komponentutveksling.
- Etterkonvertering... Kalt opp etter at datasynkronisering er fullført, men før ventende seeding skjer. Alternativer: Komponentutveksling.
- Før forsinket fylling... Ringes før utsatt seeding utføres. Logikken for sortering eller oppdatering av tabellen over objekter som skal utsettes finner du her. Alternativer: Komponentutveksling.
AML-prosedyrer
FillDataProcessingRules. Eksportprosedyren, som inneholder logikken for å fylle ut databehandlingsreglene. Inneholder kall til andre prosedyrer som legger til en regel for behandling av et spesifikt objekt i regeltabellen (se prosedyrer nedenfor Legge til). Alternativer: Retning av utveksling, Regler for databehandling
Legg til SUB_<ИмяПОД>... Et sett med prosedyrer som fyller POD-tabellen med regler for spesifikke objekter. Antall slike prosedyrer tilsvarer antallet AML-er som er gitt for denne konverteringen i Data Conversion-programmet, versjon 3.0. Alternativer: Regler for databehandling(verditabell, initialisert under utførelsen av utvekslingsøkten).
UNDER_<ИмяПОД>_Ved behandling. Prosedyren inneholder behandlerteksten Ved behandling for en spesifikk AML. Behandleren er designet for å implementere konverteringslogikken på objektnivå. For eksempel å tilordne et spesifikt objekt en bestemt POC, avhengig av innholdet i objektet. Alternativer:
- IB-data eller DataXDTO(avhengig av utvekslingsretningen):
- når du sender - objekt ( ReferenceObject,DocumentObject);
- ved mottak - en struktur med en beskrivelse av XDTO-objektet.
- Bruk av PKO... Type - Struktur... Nøkkelen inneholder en streng med PKO-navnet, og verdien til typen boolsk (ekte- PKO brukes, Å ligge- PKO brukes ikke).
- Komponentutveksling.
UNDER_<ИмяПОД>_Eksempeldata. Funksjonen inneholder behandlerteksten Ved lossing... Behandleren er designet for å implementere en vilkårlig algoritme for å velge objekter som skal losses. Returnert verdi: en rekke objekter som skal losses. Matrisen kan inneholde både referanser til infobaseobjekter og en struktur med data for lossing. Alternativer: Komponentutveksling.
POC-prosedyrer
FillObjectConversionRules. Eksportprosedyren, som inneholder logikken for å fylle ut reglene for konvertering av objekter. Inneholder kall til andre prosedyrer som legger til en regel for å konvertere et spesifikt objekt til regeltabellen (se prosedyrene nedenfor Legg til PKO). Alternativer: Retning av utveksling, Reglerkonvertering(verditabell, initialisert under utførelsen av utvekslingsøkten).
Addpco_<ИмяПКО>... Et sett med prosedyrer som fyller PQS-tabellen med regler for spesifikke objekter. Antallet slike prosedyrer tilsvarer antallet PQS som er gitt for denne konverteringen i Data Conversion-programmet, versjon 3.0. Alternativer: Reglerkonvertering(verditabell, initialisert under utførelsen av utvekslingsøkten).
PKO_<ИмяПКО>_Når du sender data. Prosedyren inneholder behandlerteksten Ved sending for en spesifikk PKO. Behandleren brukes ved lossing av data. Designet for å implementere logikken for å konvertere data i et infobaseobjekt til en XDTO-objektbeskrivelse. Alternativer:
- IB-data... Type - ReferenceObject, DocumentObject... Det behandlede objektet til infobasen.
- DataXDTO... Type - Struktur... Designet for å få tilgang til data til XDTO-objektet.
- Komponentutveksling.
- Utladningsstabel... Type - Array... Inneholder lenker til ulastede objekter, med hensyn til hekking.
PKO_<ИмяПКО>_WhenXDTODataConversion. Prosedyren inneholder behandlerteksten WhenDataConversionXDTO for en spesifikk PKO. Behandleren brukes ved lasting av data. Designet for å implementere vilkårlig logikk for konvertering av XDTO-data. Alternativer:
- DataXDTO... Type - Struktur... Egenskaper til XDTO-objektet som er forhåndsbehandlet for å gjøre dem lettere tilgjengelige.
- Mottatt data... Type - ReferenceObject, DocumentObject... Et infobaseobjekt dannet ved å konvertere XDTO-data. Ikke registrert i infobasen.
- Komponentutveksling.
PKO_<ИмяПКО>_BeforeWritingReceivedData. Prosedyren inneholder behandlerteksten Før opptak av mottatte data for en spesifikk PKO. Behandleren brukes ved lasting av data. Designet for å implementere ytterligere logikk som må utføres før du skriver et objekt til infobasen. For eksempel om du trenger å laste inn endringene i eksisterende IB-data, eller du bør laste dem som nye data. Alternativer:
- Mottatt data... Type - ReferenceObject, DocumentObject... Dataelement dannet ved å konvertere XDTO-data.
Det registreres hvis disse dataene er nye for infobasen (parameter IB-data inneholder verdien Udefinert).
V ellers Mottatt data erstatte seg selv IB-data(alle eiendommer fra Mottatt data overført til IB-data).
Hvis standard erstatning av IB-data med de mottatte dataene ikke er nødvendig, bør du skrive din egen overføringslogikk, og deretter angi parameteren Mottatt data betydning Udefinert:
- IB-data... Type - ReferenceObject, DocumentObject... Infobasedataelementet som tilsvarer de mottatte dataene. Hvis ingen samsvarende data er funnet, inneholder Udefinert.
- Konverteringsegenskaper... Type - Verditabell... Inneholder reglene for konvertering av egenskapene til det gjeldende objektet, initialisert under utførelsen av utvekslingsøkten.
- Komponentutveksling.
PCPD-prosedyrer
FillRulesConversionPredefinedData... Eksportprosedyren, som inneholder logikken for å fylle ut reglene for konvertering av forhåndsdefinerte data. Alternativer: Retning av utveksling, Reglerkonvertering(verditabell, initialisert under utførelsen av utvekslingsøkten).
Algoritmer
I programmet "Data Conversion", revisjon 3.0, er det mulig å lage vilkårlige algoritmer som kalles opp fra POD- og PKPD-behandlerne. Navn, parametere og innhold av algoritmene bestemmes når reglene utvikles.
Alternativer
FillParametersConversion. Eksportprosedyre, der strukturen er fylt med konverteringsparametere. Alternativer: OptionsConversion(type - Struktur).
Generelle prosedyrer og funksjoner
ExecuteManagerModuleProcedure. Alternativer: Navn på prosedyre(linje), Alternativer(struktur). En eksportprosedyre som er designet for å kalle en ikke-eksportmodulprosedyre, hvis navn og parametere mottas som input. Lar deg kalle en prosedyre eller funksjon linje for linje uten å bruke en metode Henrette.
ExecuteManagerModuleFunction. Alternativer: Navn på prosedyre(linje), Alternativer(struktur). Funksjon, formål er det samme RunProcedureManagerModule... Forskjellen er at den kaller en funksjon og returnerer verdien.
