IBM Enterprise Records, Version 5.1.+            

Konfigurera avvecklingsavsökningar

Innan du kör någon avvecklingsavsökning måste du konfigurera lämpliga värden. Du behöver till exempel ange namnet på Content Engine-servern som innehåller posterna och du kan begränsa avsökningen till enbart ett arkiveringsplanslager. Konfigurationsvärdena för avvecklingsavsökningar används också för avklassificeringsavsökningen. Förutom de fält som krävs för avvecklingsavsökningen kräver avklassificeringsavsökningn även ett värde för objektlagernamn och ignorerar fält som inte krävs.

Begränsning: Om du tänker köra IBM Enterprise Records-avvecklingsavsökningsverktyget i Windows behöver du tillämpa följande inställningar från kommandoprompten innan du kör verktyget så att informationen på andra europeiska språk än engelska visas korrekt:
  1. Ange Lucida Console som teckenegenskap.
  2. Ändra teckentabellen till relevant Windows ANSI-teckentabell (från 1250 till 1257). Exempel: Om franska ska visas i DOS-fönstret kör du 'chcp 1252' så att teckentabellen ändras till 1252 (teckentabell 1252 är Windows ANSI-teckentabellen för västeuropeiska latinska språk). Följ länken till tabellen Teckentabellidentifierare i slutet av detta ämne om du vill se en fullständig lista över teckentabeller.

Konfigurera avvecklingsavsökning:

  1. Öppna en kommandoprompt och byt till mappen RecordsManagerSweep.
  2. Ange något av följande kommandon:
    Alternativ Beskrivning
    UNIX ./RecordsManagerSweep.sh -DispositionSweep -configure [-profile "profilnamn"]
    Windows RecordsManagerSweep.bat -DispositionSweep -configure [-profile "profilnamn"]
  3. Ange lämpliga värden för följande fält. Du kan rensa befintliga värden genom att klicka på Återställ.
    • Längst upp i konfigurationskonsolens fönster finns etiketten Profil: profilnamn som anger vilken profil som du konfigurerar. Standardprofilen är Profil: RMSweepConfiguration.
    • Anslutning: Ange det nätverksprotokoll som du ska använda:
      • http, https om du använder ett WSI-protokoll
      • iiop, t3, jnp om du använder ett EJB-protokoll (t.ex. bör du välja iiop om Content Engine är WebSphere)
    • CE-servernamn: Ange namnet eller IP-adressen till den Content Engine-server där posterna är lagrade.
    • Portnummer: Ange WSI- eller EJB-portnummer som används av din Content Engine-server.
      • Om http eller https är valt i fältet Anslutning måste du ange ett WSI-portnummer, t.ex. 7001 for WebLogic Server, 9080 för WebSphere och 8080 för JBoss Application Server.
      • Om något av EJB-protokollen är valt i fältet Anslutning måste du ange EJB-standardportnumret för den programserver du använder, t.ex. 2809 för WebSphere.
    • URL-adress: Ange den användardefinierade sökvägen till den URL som verktyget är konfigurerat att använda för kommunikationen med Content Engine-servern. Exempel: /wsi är den sökväg som brukar användas och är standardvärdet .Om något av EJB-protokollen är valda är URL-standardadressen FileNet/Engine.
    • Namn på objektlager för arkiveringsplan (valfri): Ange namnet på det arkiveringsplansobjektlager (FPOS) där avvecklingsavsökningen ska köras. Om du inte anger något värde körs avvecklingsavsökningen på alla arkiveringsplansobjektlager på den angivna Content Engine-servern.

      Ett värde för objektlagernamn krävs för att köra avklassificeringsavsökningen.

    • Kör för posttyper (valfri):
      • Ange True om avvecklingsavsökningen ska kontrollera alla posttyper för att se om det finns några ändringar av deras avvecklingsscheman. Om avvecklingsschemat för någon posttyp har ändrats uppdaterar avvecklingsavsökningen alla entiteter som hör till den posttypen.
      • Ange värdet False om posttyperna ska ignoreras. Som standard bearbetas inte alla poster.
    • Entitets-GUID (valfritt): Ange GUID för den IBM Enterprise Records-behållare där avvecklingsavsökningen ska köras. Avvecklingsavsökningen körs mot den angivna behållaren och alla dess underordnade. Som standard är noden tom och alla entiteter bearbetas. Avklassificeringsavsökningen ignorerar entitetens GUID-värde och körs alltid mot hela objektlagret.
    • Användar-ID: Ange det användar-ID som avvecklingsavsökningen använder för inloggningen till Content Engine för att utföra beräkningar och till Process Engine för att starta arbetsflöden. Användaren måste tillhöra processadministratörsgruppen, ha administratörsbehörighet för objektlager på samt postadministratörsbehörigheter.
    • Lösenord: Ange lösenordet för användar-IDt.
    • FIPS 140-2-läge (valfritt): Välj eller Av. I FIPS 140-2-läge använder IBM Enterprise Records FIPS 140-2-godkända krypteringsleverantörer, IBMJCEFIPS (certifikat 376) och/eller IBMJSSEFIPS (certifikat 409) eller IBM Crypto for C (ICC) (certifikat 384) för krypteringen. Certifikaten listas på NIST-webbplatsen på adressen http://csrc.nist.gov/cryptval/140-1/1401val2004.htm. Om du väljer och säkerhetsadministratören inte konfigurerar systemet för FIPS 140-2-läge, visar IBM Enterprise Records ett felmeddelande. Säkerhetsadministratören måste ändra filen java.security. Se uppgiften Konfigurera IBM Enterprise Records för FIPS 140-2-läge. IBM Enterprise Records supports FIPS 140-2-kryptering enbart i WebSphere Application Server.
    • PE-anslutningspunkt: Ange namnet på den anslutningspunkt som skapades på Content Engine-servern under installationen. Värdet krävs för anslutning till Process Engine-servern, utom om konfigurationen bara är för autoförstöring. I det senare fallet kan fältet lämnas tomt.
    • Batchstorlek för uppdatering (valfritt): Ange hur många entiteter som kan uppdateras i en batch. Standardvärdet är 1000.
    • Batchstorlek för läsning (valfritt): Ange hur många entiteter som kan läsas i en batch. Standardvärdet är 10 000.
    • Antal trådar (valfritt): Ange hur många bearbetningstrådar som IBM Enterprise Records ska använda under avvecklingsavsökningen. Bästa praxis är att ange en tråd för varje logisk processor på Content Engine-servern. Exempel: Ange 8 om det finns åtta logiska processorer på Content Engine-servern. Standardvärdet är 1.
    • Cachestorlek för poster som arkiveras på flera ställen: Konfigurera en cachestorlek för multiposter. Standardvärdet är 10 000. Som standard sparar avsökningen upp till 10 000 IDn förposter som arkiverats på flera ställen i cache. För optimala prestanda måste antalet i fältet Cachestorlek för poster som arkiveras på flera ställen vara större än det totala antalet poster som arkiveras på flera ställen i systemet för att undvika sökning på Content Engine-servern efter IDn som inte fanns i cache. Men om du anger ett för stort cachevärde kan minnesresurserna på servern uttömmas.
    • Aktivitetsloggfil (valfritt): Ange namnet på den felfil som skapas av avvecklingsavsökningen. Som standard skapar den en fil med namnet DispositionSweepActivity.log i mappen ../EnterpriseRecords/RecordsManagerSweep. Om avvecklingsavsökningen körs utan fel innehåller felfilen noll byte. Eftersom avvecklingsavsökningen delar vissa egenskaper med avklassificeringsavsökningen, skriver den också viss information till filen DeclassificationSweepActivity.log.
    • Kör för vital (valfri):
      • Välj True om alla postkategorier, postmappar, volymer och poster ska kontrolleras för att se om ändringar har gjorts av vitala metadata. Om avvecklingsschemat för någon posttyp har ändrats uppdaterar avvecklingsavsökningen alla tillhörande entiteter.
      • Välj False om vitala metadata ska ignoreras. Som standard kontrolleras inte vitala metadata.
  4. Klicka på Konfigurera.
  5. Klicka på Återställ om du vill återgå till standardvärden. Klicka på Avsluta om du vill stänga konsolen för konfigurering av avsökningar utan att göra några ändringar.


Feedback

Senast uppdaterat: Augusti 2011


© Copyright IBM Corp 2011.
Detta Informationscenter bygger på Eclipse-teknik. (http://www.eclipse.org)