Skriv en avansert Excel-dataimport med Agile Platform

Et av de mest vedvarende motbydelige kravene i utviklingshistorien er behovet for å importere data til en applikasjon fra Microsoft Excel. Vi vet hvor mye brukere liker å bruke Excel som et diverse catch-all-program (spesielt små bedrifter som ser ut til å styre hele organisasjonene fra det), så dataimporten er viktig, men det er vanskelig å håndtere Excel.

Det er kjent at det er problematisk å kjøre Office på serveren (det skaper en minnelekkasje), som utelukker å bruke Visual Studio Tools for Office. Tredjepartskomponenter er tilgjengelige, men de gode er vanligvis ganske dyre, og gratis og åpen kildekode er vanligvis buggy, utdaterte eller mangler funksjoner. Heldigvis for meg, det tok timer snarere enn dager å lage en dataimport i OutSystems Agile-plattformen; Jeg brukte komponenter innebygd i systemet og lærte hva jeg skulle gjøre på noen få minutter. Jeg viser deg hva jeg gjorde for å skrive en avansert dataimport for Excel 2007/2010.

Excel-dataimport

Det første trinnet i dataimporten er å hente dataene fra brukeren. For dette bruker vi FileUpload Widget - bare plasser den på skjermen og gi den et navn. Deretter oppretter du en ny knapp og lenker den til en ny handling for å utføre importen. Dette vil sette en boks på skjermen for at brukeren skal velge sin lokale fil og deretter laste den opp.

I handlingen begynner den virkelige moroa. Det som gjør dette så sinnsykt enkelt, er en enkel innebygd handling som er tilgjengelig i Verktøykassen: ExcelToRecordList. Forresten, det er også en RecordListToExcel-widget, som gjør akkurat det du tror, ​​og er flott for å skrive dataeksport. Bruke denne handlingen tar Excel-filen og gjør den til en RecordList ved å bruke Record Definition du oppgir. Her er noen notater om hvordan den analyserer filen:

  • Du kan spesifisere hvilket ark du vil lese. Hvis du ikke gjør det, ser det etter "Sheet1", og hvis det ikke er tilgjengelig, bruker det det første arket i arbeidsboken.
  • Hvis antall kolonner i arket samsvarer med antall kolonner i postdefinisjonen, vil det lese dem fra venstre til høyre for å fylle ut posten. Ellers vil den bruke dataene i rad 1 for å matche kolonner til Attributter (jeg anbefaler dette på det sterkeste).
  • Hvis to posttyper i definisjonen har attributter med samme navn, skal kolonnenavnet i rad 1 skille den som det betyr å bruke et kolon for å skille postens type fra kolonnenavnet (f.eks. "Kunden: Navn" og "Del: Navn").
  • Rekorddefinisjonen din kan inneholde enheter eller strukturer (dette vil bli viktig om et øyeblikk).
  • Recorddefinisjonen kan ikke inneholde noen enheter eller strukturer med attributter av typen BinaryData.

Den første ideen min var å bruke destinasjonsenheten til importen i datadefinisjonen; dette er helt greit i mange situasjoner, men jeg treffer raskt noen få vegger. For det første hadde en av enhetene jeg importerte en BinaryData-attributt, og jeg hadde virkelig ikke lyst til å omskrive alle stedene den ble brukt til å sette den i sin egen enhet. For det andre refererer noen av enhetene jeg trengte å importere til andre enheter. For eksempel er PART-enheten min knyttet til LEVERANDØR, som jeg også importerte. Selv om de ikke begge skulle komme inn på samme tid, ville jeg absolutt ikke tvinge brukerne mine til å finne ut ID-nummerene for de tilknyttede enhetene.

Så jeg rakte inn i bagasjen med triks og kom frem til en enkel løsning: Jeg valgte enheten, høyreklikk og valgte Kopier, og gikk deretter helt til toppen av datatreet, høyreklikk og valgte Lim inn som. ... Jeg valgte deretter Struktur, som ga meg en struktur med identiske attributter som enheten jeg ønsket. Deretter fjernet jeg BinaryData-attributtene og Id-attributtet. Deretter erstattet jeg en tekstenhet, alle attributter som refererte til en annen enhet. For eksempel, der mitt PART-enhet har en leverandørattributt som peker til LEVERANDØR, erstattet jeg den med en tekstattributt kalt Leverandørnavn.

Ved å bruke denne posten i postdefinisjonen min for ExcelToRecordList Action, var det på tide å gå videre. Jeg brukte en ForEach Action for å iterere over den resulterende postlisten. Innen ForEach var mitt første skritt å slå LEVERANDØR-enheten etter attributten Leverandørnavn i de importerte dataene, noe som var enkelt nok. Deretter brukte jeg en tilordnet handling for å kopiere alle dataene fra den importerte strukturen til en lokal variabel av typen Record med en definisjon av LEVERANDØR, samt noen standard dataverdier og leverandøridentifikatoren som er nødvendig for leverandørattributtet til PART. Denne lokale variabelen blir sendt til CreatePART-handlingen som er definert av enheten.

Én enhet (KUND) var spesielt vanskelig - den refererte til en annen enhet (ADDRESS) tre ganger (PhysicalAddress, MailingAddress og BillingAddress). Hva å gjøre? Lett! Jeg kopierte ADDRESS-enheten i tre strukturer (ForImportPhysicalAddress, ForImportMailingAddress og ForImportBillingAddress), og i hver av dem endret jeg attributtene til å være i form av "PhysicalAddressCity" eller "MailingAddressLine1." Selv om jeg bare kunne ha latt navnene være like og brukt navnene "PhysicalAddress: City" eller "MailingAddress: Line1" i Excel-kolonneoverskriftene, er min måte mye enklere for brukerne som skal jobbe med Excel-filen. I importen for dette arket opprettet jeg først hver ADRESSE-enhet separat, og fylte deretter de resulterende ID-ene inn i KUNDEN-enheten før jeg opprettet den.

Som en ekstra bonus gjorde jeg det tunge løftet i en eSpace Action, og ga inn BinaryData fra opplastningen. Jeg opprettet en outputvariabel av typen RecordList, med en definisjon av PART for my Action. Etter å ha opprettet hver enhet i databasen, tok jeg den resulterende IDen, la den til den lokale PART-postvariabelen og brukte ListAppend for å legge den til Output Variable. Med dette har jeg muligheten til å vise til brukeren hvilke poster som ble importert etter den vellykkede importen.

Det eneste problemet jeg hadde med denne prosessen var at jeg mistet mye tid fordi jeg redigerte en annen Excel-fil enn den jeg faktisk testet med. Utenom det tok prosessen meg omtrent to timer (inkludert å finne ut strukturen-trikset) å importere for fem enheter, hvorav noen var ganske kompliserte. Jeg vet at bruk av tredjepartskomponenter i .NET-kode ville tatt meg mye, mye lenger.

Les de andre TechRepublic-innleggene mine om Agile Platform
  • Lage et påloggingssystem for OutSystems Agile Platform
  • Genererer unike strenger i smidig plattform
  • Livssyklusen min i smidig plattform

J.Ja

© Copyright 2021 | pepebotifarra.com