<< Click to Display Table of Contents >> Importformat för CSV-filer |
Tolkar mappningfiler som används av bios.servlets.servercall.imp.Importer.
Exempel på mappningsfil:
•#Ini-fil för en katodisk kabel
•delimiter:;
•mode:new
•otype:90433
•subtype:1
•state:0
•0:55147:CABLE_ID:STRING
•1:55147:CABLE_DESC:STRING
Alla texter efter # i en rad antas vara en kommentar och tomma rader ignoreras.
Ordningen för konfigureringsparametrarna är viktig, parametrarna måste organiseras som det är beskrivet i det här avsnittet. |
1. delimiter |
På den första raden måste avgränsaren anges. Du kan lägga vilken sträng du vill som avgränsare i dina datafiler som värdet på parametern eller valfritt antal och kombination av 'tab' och 'mellanslag' för att använda en eller flera tabb- eller mellanslagstecken. Exempel: delimiter:tab delimiter:space |
||
2. surrounding_char |
Detta ger möjlighet att specificera ett tecken som omger data för ett fält. Om detta är specificerat så kommer det bara beröra den data som har tecknet i början och i slutet. Ingenting kommer att hända om tecknet inte finns där. Två användbara tecken för stunden är: " och '. Om någonting annat är specificerat som ett tecken, eller om det inte finns något specificerat tecken, kommer ingenting att bli gjort. Exempel: surrounding_char:" |
||
3. decimal_separator |
Denna kan användas om man vill använda annat än punkt (.). Exempel: decimal_separator:, |
||
4. mode |
Detta specificerar läget. Det finns sex läge, new, unique_new, add, upsert , modify och dynamic. •new - Nya objekt kommer att skapas. Kommer inte att kontrollera om objektet redan finns, alltså kommer nya objekt (med olika DP_OID) att skapas med samma data. •unique_new - Nya objekt kommer att skapas. Om det redan finns kommer det att ignoreras. Bör konfigureras som läget new men med id-parameter. •add - Nya komponenter kommer adderas till existerande objekt. •upsert - Skapar ett nytt objekt om det inte finns, annars uppdaterar befintligt objekt. Bör konfigureras som läget new men med id-parameter. •modify - Modifiera eller lägg till komponenter till existerande objekt, rader för icke existerande objekt kommer att loggas. Bör konfigureras som läget add plus en eller flera rader med cid-parametrar för varje komponenttyp, se cid nedan. •dynamic - Välj vilket läge som ska användas för varje rad beroende på innehållet i något fält på raden som bearbetas. Se fler parametrar längre ner för dynamik. |
||
5. otype |
Otypen kan specificeras med ett fast värde eller en kolumn i datat som värdet kan läsas ifrån. Exempel, importera alla rader till ett objekt med otyp 50001: otype:50001 Exempel, importera rader till objekt som är beroende av en otyp specificerad i fält 3: otype:col:3 |
||
6. subtype |
Ska endast specificeras om läget är new, upsert eller dynamic (om det senare kan hantera nytt och/eller upsert). subtype:col:7 |
||
7. state |
Ska endast specificeras om läget är new, upsert eller dynamic (om det senare kan hantera nytt och/eller upsert). state:1 |
||
8. forcencolumns |
Tvingande koll av antal kolumner. Du kan tvinga importen att klaga på om en rad innehåller ett antal kolumner som skiljer sig från det antal som var definierat med Forcencolumns. forcencolumns:12 |
||
9. date |
Om ett specifikt datumformat ska användas kan du specificera det. Exempel: date:yyyyMMdd Datumformatet bör följa formatet för java.util.SimpleDateFormat. Om du inte anger ett format kommer åååå-MM-dd att användas. |
||
10. verify_fields |
Sätt till true om du vill verifiera data innan importen. Fälten verifieras en och en under importen. Om datat inte skulle uppfylla kriterierna så kommer ett felmeddelande att bifogas till logfilen och datat kommer att ersättas med null, så not null-fält kommer att generera två felmeddelanden. Exempel: verify_fields:true |
||
11. encoding |
Teckenkodningen för det importerade datat. Default är ISO-8859-1. Om mer än ett ImportFormats används på samma datafiler används teckenkodningen för den först använda. Exempel: encoding:ISO-8859-1 |
||
12. class |
Specifiera parameterklassen. Exempel: class:sys.nis.servlets.imp.LinkImporter Värdet ska vara en kolonseparerad lista av klasser som implementerar gränssnittet PostImporter. Metoden PostImport.postImport () åberopas för varje klass när en rad har importerats. |
||
13. linestringcol |
Läs under Mappning om linjesträng för förklaring. |
||
14. id |
Om läget är add, upsert, modify eller unique_new, ska nästa rad innehålla en specifikation för hur objektet hittas som man ska lägga till någonting för. Exempel: id:0:100000:CUSTOMER_NO Nyckelordet ska vara id. Den första delen av parametern är den kolumn eller de kolumner med data som ska matchas. Den andra delen är ctypen för komponenten som det ska matchas till. Den tredje delen är fältet för komponenten som det ska matchas mot. Det går att specificera många id-villkor. Om du vill hitta ett objekt med ett kodlistat värde måste du göra så här: id:1:22302:OBS_CODE:CODELISTED:OBS_TEXT
Du kan också definiera en specifik klass som definierar en mer involverad metod för att hämta objekt för uppdatering med till exempel: idclass:sys.nis.servlets.imp.ParentLinkIdFetcher
Nyckelordet ska vara idclass, nästa del är namnet på klassen som implementerar ImportedIdFetcher-gränssnittet. En sådan id-hämtare kan också behöva ytterligare parametrar som är specifika för sina egna krav. De specificeras med nyckelordet idclassparam: idclassparam:PARENT_LNK_CTYPE:5000
Dessa parametrar kan nås av id-hämtningsklassen som en sträng till sträng-karta som lagrar paramName->paramValue-par. Se den specifika klassdokumentationen för detaljer.
|
||
15. cid |
Om läget är Modify, kommer nästa nyckelord att berätta hur komponenterna som ska ändras kan hittas. Formatet ser likadant ut som för id. Om det inte hittas några komponenter för ett objekt så kommer en ny komponent att skapas. |
||
16. preprocessor |
Konfigureringar för preprocessorer är en semikolonseparerad lista. Varje element av listan är en konfig-fil och en eller flera sektioner av konfig-filen avskiljs med kommatecken. Varje sektion måste innehålla parameterklassen, som värderar namnen som klass som implementerar ImporterPreprocessor. För var och en av klasserna kommer metodprocessen att anropas för varje rad av det importerade datat innan ett importförsök utförs. Klasserna används i den ordning de specificeras. Exempel: preprocessor:^app/fpgas/conf/cust_fov/customer_import/preprocessor.conf,equipment_translator |
||
17. constant |
Några komponentfält kan sättas till ett konstant värde. Formatet liknar den för kolumnmappning förutom kolumnen nummer som ersatts med nyckelordskonstanten och ett extra kolon i slutet följt av konstantdatat. Exempel: constant:23000:IMP_SOURCE:STRING:FPGAS Ett godtyckligt antal av konstantfält kan specificeras. Accepterade datatyper är STRING, DATA, DATE, BOOLEAN och INTEGER. Typen DATE stöder nyckelordet SYSDATE som ger ett datum som följer det angivna datumformatet eller standard om inget anges för den aktuella tiden när konfigurationen läses, någon precision utöver dagar kanske inte är användbar.
|
||
18. constant_set_on_upsert |
Sätt fältet till ett konstant värde endast när en rad infogas/uppdateras. Detta värde kommer inte att jämföras med det befintliga värdet i databasen för att utföra en uppdatering. Utöver det är den identisk med konstant. |
||
19. dynamic |
Om läget är inställt på dynamic bör varje rad innehålla något fält med någon känd token för att indikera vilket läge den ska använda. Det är viktigt att veta vilka lägen som förväntas eftersom andra konfigurationsparametrar måste specificeras. T.ex. om add kan väljas för en rad behövs id-parametern, för modify behövs cid-parametern. dynamic:column:# - anger i vilken kolumn token ska finnas. Räknar från noll. Bör visas före följande lägen. dynamic:mode:? - En eller flera för varje läge (så olika tokens kan användas för samma åtgärd). Minst ett läge krävs (men inte alla). Exempel: dynamic:column:8 dynamic:new:I dynamic:modify:Up dynamic:modify:Rm Tokens kommer att letas efter i den 9:e kolumnen, strängen "I" kommer att tillämpa det nya läget. Strängarna "Up" och "Rm" kommer båda att tillämpa läget modify. |
||
20. Skip |
Skip anger vilka rader som ska hoppas över när vissa kolumner är lika med en viss sträng. Att använda skip är valfritt och det är möjligt att anropa det flera gånger. Det är obligatoriskt att ange både kolumn och söksträng
Exempel 1 (hoppa över varje rad där 0:e kolumnen är lika med "10"): skip:0:10
Exempel 2 (hoppa över varje rad där 5:e kolumnen är lika med "test"): skip:5:test
Exempel 3 (hoppa över varje rad där 15:e kolumnen är lika med "message"): skip:15:message
Exempel 4 (hoppa över varje rad där den 20:e kolumnen är tom, dvs är lika med ""): skip:20: Om raden bara har 19 värden kommer den inte att hoppas över |
||
21. Take |
Take anger vilka rader som ska importeras när vissa kolumner är lika med en viss sträng. Alla andra rader hoppas över. Att använda take är valfritt och det är möjligt att anropa det flera gånger. Det är obligatoriskt att ange både kolumn och söksträng.
Exempel 1 (importera endast rader där 0:e kolumnen är lika med "10"): take:0:10
Exempel 2 (importera endast rader där 5:e kolumnen är lika med "A" eller "B"): take:5:A take:5:B
Exempel 3 (importera endast rader där 5:e kolumnen är lika med "A" eller 6:e kolumnen är lika med "B"): take:5:A take:6:B Om raden bara har 4 värden kommer den inte att importeras |
||
22. Skipfirst |
Skipfirst kan användas när ett antal rader i början av datafilen behöver hoppas över. Att använda skipfirst är valfritt. Exempel (hoppa över de första 4 raderna): skipfirst:4 |
||
23. Mapping |
En specifikation om hur kolumnen ska mappas. En rad per kolumn. Exempel 1: 1:100001:ADDRESS_TYPE:STRING 2:100001:STREET:STRING 5:100001:COUNTRY:STRING 6,7:101010:SHAPE:SYMBOL:ST74:RT90
Exempel 2: B:100001:ADDRESS_TYPE:STRING C:100001:STREET:STRING F:100001:COUNTRY:STRING G,7:101010:SHAPE:SYMBOL:ST74:RT90
Exempel med fältnamn: SPRINKLER:7201:SPRINKLER:STRING "LSO 2:3":7201:LSO_2_3:STRING PERMIT\, DATE:7201:PERMIT_DATE:STRING N,E:451:SHAPE:SYMBOL
Precis som med id-specifikation är den första delen av parametern kolumnen eller kolumnerna av data som ska matcha, kolumnnumrering nollindexeras om heltal används. Det är också möjligt att använda kolumnpositioner i Excel-stil där A = 0. Om fältnamn används spelar ordningen ingen roll. Fält som innehåller : kan citeras med dubbla citattecken. Komma kan undvikas. Den andra delen är vilken ctyp av objektet som mappningen ska påverka. Den tredje delen av mappningen är fältet där data ska placeras. Den sista delen beskriver vilken typ av mappning som ska utföras. Importören förstår typerna: •STRING: Data importeras som den är, skickas som en sträng till databasen. •DATA: Data importeras som den är, skickas som en sträng till databasen. Använd STRING vid ny mappning. Använd INTEGER för numeriska värden. •INTEGER: Den inmatade strängen tolkas som ett heltalsvärde. •DOUBLE: Inputsträngen tolkas som en dubbel. Konfigurera decimal_separator om annat än punkt (.). •DATE: Data tolkas enligt det specificerade datumformatet, se avsnitt ovan. •BOOLEAN: Data tolkas till ett booleanvärde. 1 och true tolkas till TRUE (1 i Oracle), allt annat tolkas som FALSE (0 i Oracle). 1 tolkas som TRUE för att underlätta importer av data från andra system med hjälp av 1 som ett true-värde. •NULL_CONSTANT_TYPE: Använd den här typen i samband med en konstant för att ställa in specifika kolumnvärden till null i kundimporten. •SYMBOL: Datavärden tolkas som koordinater och en symbolkomponent skapas. Koordinaterna hämtas från kolumnerna som specificeras som x, y, [z, rotation]. Exempel: 6,7:101010:SHAPE:SYMBOL:ST74:RT90 1,2,3:101017:SHAPE:SYMBOL:ST74:RT90 1,2,3:101017:SHAPE:SYMBOL:ST74:GET_CS_FROM_CTYPE 1,2,-1:101017:SHAPE:SYMBOL:ST74:GET_CS_FROM_CTYPE 1,2,-1,4:101017:SHAPE:SYMBOL:ST74:GET_CS_FROM_CTYPE Z-kolumnen är valfri om inte en rotation anges. Om det inte finns någon z-kolumn men en rotation önskas ska z-kolumnen sättas till -1. Standardvärdet för rotation är 0,0. Om koordinaterna ska transformeras under import kan du ange vilket koordinatsystem som ska översättas från och till som den femte och en sjätte delen av mappningen. Du kan också ställa in flaggan "GET_CS_FROM_CTYPE". I det här fallet hämtas databastabellnamnet för ctype och denna tabell kontrolleras för målkoordinatsystemet. I exemplet ovan uttrycks symbolerna i ST74 i datafilen, men lagras i RT90 i databasen. I det tredje exemplet hämtas målkoordinatsystemet automatiskt. •TEXT: Datavärdena tolkas som koordinater och en textkomponent skapas. Koordinaterna/rotationen/texten hämtas från de kolumner som anges som x,y,[z],r,t där r = rotationskolumn, t = textkolumn. Om r = -1 är rotation = 0,0. Om t = -1 så hämtas texten från texttriggerinformation. Exempel: 1,2,3,7,6:16597:SHAPE:TEXT:SWEREF99 13 30:SWEREF99 13 30 # with z value 1,2,3,-1,-1:16610:SHAPE:TEXT:SWEREF99 13 30:SWEREF99 13 30 # with z value 1,2,-1,-1:16610:SHAPE:TEXT:SWEREF99 13 30:SWEREF99 13 30 # without z value För transformationer, se SYMBOL. •LINESTRING: Värdena av flera rader tolkas som koordinater av en linjesträngskomponent. För att veta hur många rader med koordinater som skapar en linjesträng ska en egenskap specificeras för kolumnen med ett unikt id för varje linjesträng. Detta ska specificeras före kolumnmappningen.
Exempel på format: otype:533 subtype:1 state:1 linestringcol:3 0,1,2:1024:SHAPE:LINESTRING 3:1025:NAME:STRING
Motsvarande data: 98989898,2363243,12,NOR78 98989894,2363245,12,NOR78 98989568,2363246,12,NOR78 98989413,2363234,12,NOR79 98989884,2363291,12,NOR79 98989814,2363276,12,NOR81 98989766,2363209,12,NOR81 98982345,2363288,12,NOR81
Denna mappning och data kommer att resultera i 3 linjesträngsobjekt av otype 533. Den första kommer att ha en datakomponent av ctype 1025 med fält NAME satt till NOR78 och en grafisk komponent av ctype 1024 med två punkter. Den andra kommer att ha en datakomponent av ctype 1025 med fält NAME satt till NOR79 och en grafisk komponent av ctype 1024 med två punkter. Den tredje kommer att ha en datakomponent av ctype 1025 med fält NAME satt till NOR81 och en grafisk komponent av ctype 1024 med tre punkter. Du kan specificera koordinatsystem på samma sätt för en LINESTRING som för en SYMBOL •OGC WKT (Well Known Text): Värdet ska vara en giltig OGC WKB-geometri. Exempel på format: otype:533 subtype:1 state:1 0:1024:SHAPE:WKT 1:1025:NAME:STRING
Motsvarande data: LINESTRING (98989898 2363243, 98989894 2363245, 98989568 2363246),NOR78 LINESTRING (98989413 2363234, 98989884 2363291),NOR79 LINESTRING (98989814 2363276, 98989766 2363209, 98982345 2363288),NOR81
Denna mappning och data kommer att resultera i 3 linjesträngar, precis som i exempel för LINESTRING, men med Z-komponenten i alla hörn satt till 0.0. För 3D-geometrier använd bokstaven "Z" efter geometritypen enligt exemplen för OGC (Open Geospatial Consortium) WKT på https://postgis.net/docs/using_postgis_dbmanagement.html#OpenGISWKBWKT. Den data som motsvarar mappningen kommer då se ut så här: LINESTRING Z (98989898 2363243 12, 98989894 2363245 12, 98989568 2363246 12),NOR78 LINESTRING Z (98989413 2363234 12, 98989884 2363291 12),NOR79 LINESTRING Z (98989814 2363276 12, 98989766 2363209 12, 98982345 2363288 12),NOR81
Du kan ange koordinatsystem på samma sätt för en WKT som för en SYMBOL. Standarden EWKT (Extended WKT) stöds inte. LRS "M"-komponenten stöds inte. •OGC WKB (Well Known Binary): Värdet ska vara en giltig OGC WKB-geometri. Exempel på format: otype:533 subtype:1 state:1 0:1024:SHAPE:WKB 1:1025:NAME:STRING
Motsvarande data: 000000000200000003419799DD28000000414207B580000000419799DD18000000414207B680000000419799D800000000414207B700000000,NOR78 000000000200000002419799D594000000414207B100000000419799DCF0000000414207CD80000000,NOR79 000000000200000003419799DBD8000000414207C600000000419799DB18000000414207A4800000004197996724000000414207CC00000000,NOR81
Denna mappning och data kommer att resultera i 3 linjesträngar, precis som i det ovanstående WKT-exemplet. Du kan specificera koordinatsystem på samma sätt för en WKT som för en SYMBOL. Standarden EWKB (Extended WKB) stöds också, men SRID:en kommer att ignoreras. LRS "M"-komponenten stöds inte. Tecknen "\x" i början av den hexadecimala representationen av byte är valfria. •EWKB PostGIS (Extended Well Known Binary för PostGIS): Värdet ska vara en giltig OGC WKB-geometri med PostGIS-tillägg. Beskrivningen av formatet och skillnaderna mellan OGC-standard kan hittas här. Exempel på format: otype:533 subtype:1 state:1 0:1024:SHAPE:WKB_POSTGIS 1:1025:NAME:STRING
Motsvarande data: \x01020000000300000000000028dd99974100000080b507424100000018dd99974100000080b607424100000000d899974100000000b7074241,NOR78 \x01020000000200000000000094d599974100000000b1074241000000f0dc99974100000080cd074241,NOR79 \x010200000003000000000000d8db99974100000000c607424100000018db99974100000080a4074241000000246799974100000000cc074241,NOR81
Denna mappning och data kommer att resultera i 3 linjesträngar, precis som i det ovanstående WKT-exemplet. Du kan specificera koordinatsystem på samma sätt för en WKT som för en SYMBOL. Standarden EWKB (Extended WKB) stöds också, men SRID:en kommer att ignoreras. LRS "M"-komponenten stöds inte. Tecknen "\x" i början av den hexadecimala representationen av byte är valfria. •CODELISTED: En annan specialform som informerar importen att hämta data från en kodlista. Exempel: 8:19033:SUBSCR_TYPE:CODELISTED:CODETEXT
Det sista fältet informerar om vilket fältnamn som ska användas som nyckel. Det kan finnas flera kolumner och nyckelfält: 3,4,5:19211:EQUIPMENT:CODELISTED:EQUIP_MAKE,EQUIP_MODEL,EQUIP_TYPE •CODELISTED_ADD: Är i huvudsak samma som CODELISTED med skillnaden att kodlistetexter som inte finns i kodlistan skapas och ett codenum tilldelas texten. |