OpenText Content Server patří mezi nejrozšířenější ECM systémy pro správu dokumentů OpenText. Firmy na něj spoléhají při řízení smluv, projektové dokumentace, integraci se SAPem i při dodržování compliance.
Je robustní, spolehlivý a škálovatelný. Přesto se v praxi objevují rizikové scénáře, které mohou způsobit nepříjemnosti. Ne proto, že by Content Server selhal, ale proto, že je tak komplexní, že vyžaduje správné nastavení, monitoring a péči.

Podívejte se na 5 nejčastějších problémů v OpenText Content Serveru, se kterými jsme se v praxi setkali, a zjistěte:

  • co se může stát,
  • jak reagovat, když nastane incident,
  • jak těmto situacím předejít.
Diagram 5 rizikových scénářů v OpenText Content Serveru a prevenc

Rizikový scénář č. 1 – zaseknuté workflow v OpenText Content Serveru

Co se stalo

Firma využívala Content Server workflow pro schvalování smluv. Při úpravě workflow logiky se objevila chyba – podmínka nikdy nevrátila „true“. Procesy se tvářily jako běžící, ale smlouvy reálně nepostupovaly dál.

Dopad

  • Klíčové smlouvy nebyly podepsané včas.
  • Obchodní příležitosti se zpozdily.
  • Právní oddělení muselo improvizovat.

Co dělat, když workflow v OpenText Content Serveru spadne

  1. Zkontrolovat stav instancí v Personal → Workflows.
  2. Zastavit nové spouštění workflow.
  3. Exportovat seznam uvízlých smluv a řešit manuálně.
  4. Pokud nelze chybu opravit, vrátit workflow na předchozí verzi.

Prevence a best practices

  • Nastavit alerty pro workflow, která běží déle než X dní.
  • Používat dashboard s počtem schválených a čekajících smluv.
  • Testovat změny workflow na reálných datech.
  • Zdokumentovat kritická workflow a mít připravený rollback plán.

Vychytávky z praxe

  • SQL job, který denně hlídá workflow starší než 5 dní.
  • „Shadow workflow“ – testovací smlouva týdně.
  • Automatické eskalace po 3 dnech nečinnosti.
  • Uchovávat Workflow Trace logy minimálně 30 dní.

Rizikový scénář č. 2 – upgrade OpenText Content Serveru a ztracená metadata

Co se stalo

Firma prováděla upgrade Content Serveru z verze 16 na 22.2. Testovací prostředí obsahovalo jen minimum dat. Po nasazení do ostrého provozu se ukázalo, že část vlastních atributů se nezmigrovala. Dokumenty sice byly uložené, ale chyběla metadata (čísla smluv, projektové kódy).

Dopad

  • Dokumenty nebyly vyhledatelné.
  • Projekty ztratily kontinuitu.
  • Chaos v dokumentaci a nárůst manuální práce.

Co dělat, když se metadata v OpenText Content Serveru ztratí

  1. Analyzovat rozsah problému – zjistit, kolik dokumentů je bez metadat.
  2. Obnovit metadata ze zálohy databáze (snapshot).
  3. Použít ID dokumentů pro párování obsahu a metadat.
  4. V krajním případě provést rollback upgradu.

Prevence a best practices

  • Před upgradem vždy provést snapshot metadat všech dokumentů.
  • V testovacím prostředí používat reálná data s vlastními atributy.
  • Mít připravený a otestovaný rollback plán.

Vychytávky z praxe

  • Metadata Snapshot skript → export atributů do CSV pro porovnání před/po upgradu.
  • Hash kontrola souborů (MD5/SHA) pro jistotu, že se dokumenty neztratily.
  • Kontrolní skript, který označí dokumenty s prázdnými klíčovými poli.

Tyto problémy se v OpenText Content Serveru objevují častěji, pokud není systém správně nastavený.

Rizikový scénář č. 3 – výpadek serveru v OpenText Content Serveru

Co se stalo

Výrobní firma provozovala OpenText Content Server na vlastním hardware. Po selhání RAID řadiče došlo k výpadku. Disaster recovery plán existoval, ale nikdy se netestoval. Poslední záloha byla stará tři týdny a tým nevěděl, jak rychle zprovoznit náhradní instanci.

Dopad

  • 2 dny bez přístupu k dokumentům.
  • Zastavené projekty a ztráta produktivity.
  • Náklady v řádu stovek tisíc.

Co dělat, když Content Server spadne

  1. Okamžitě informovat uživatele a management s časovým odhadem obnovy.
  2. Přepnout na náhradní hardware nebo virtuální prostředí.
  3. Obnovit databázi a content store ze zálohy.
  4. Zkontrolovat konzistenci dat.
  5. Analyzovat příčinu a dokumentovat postup.

Prevence a best practices

  • Zálohovat databázi i content store denně.
  • Zavést cluster/failover řešení.
  • Pravidelně testovat disaster recovery scénář (min. 1× ročně).

Vychytávky z praxe

  • DR drill – jednou ročně spuštění Content Serveru z poslední zálohy.
  • Externí syslog server pro uchování logů.
  • Hot spare disky pro rychlejší rebuild RAIDu.
  • Monitoring HW (SMART, teplota, výkon).

Nemusíte řešit OpenText Content Server sami

Jsme tu od toho, abychom vám ušetřili čas i starosti. Postaráme se o správné nastavení i podporu vašeho OpenText Content Serveru.

Rizikový scénář č. 4 – integrace Content Serveru se SAPem a neaktuální konektory

Co se stalo

Integrace mezi Content Serverem a SAPem fungovala roky. Po upgradu SAPu se změnila struktura dat a volané funkce. Konektor nebyl aktualizován → dokumenty se přestaly ukládat správně. Bez monitoringu si toho nikdo týdny nevšiml.

Dopad

  • Dokumenty visely jen v Content Serveru, SAP je „neviděl“.
  • Logistika a obchod neměly aktuální podklady.
  • Dodavatelé čekali na potvrzení, která nikdo neschválil.

Co dělat, když integrace SAP–Content Server přestane fungovat

  1. Zastavit synchronizaci, aby se chyba nešířila.
  2. Zkontrolovat logy konektorů a zjistit, od kdy problém trvá.
  3. Vyexportovat seznam chybějících dokumentů.
  4. Aktualizovat konektor a znovu spustit integraci.

Prevence a best practices

  • Po každé změně v SAPu testovat integrační scénáře.
  • Nastavit monitoring přenosů a alerty při selhání.
  • Pravidelně auditovat integrační body.

Vychytávky z praxe

  • Denní testovací dokument pro ověření funkčnosti.
  • Alert při neúspěšném přenosu.
  • Kontrolní report s počtem přenesených dokumentů.
  • Jasně stanovený vlastník integrace.

Tyto problémy se v OpenText Content Serveru objevují častěji, pokud není systém správně nastavený.

Rizikový scénář č. 5 – oprávnění v OpenText Content Serveru a omylem smazaný workspace

Co se stalo

Firma měla nastavená oprávnění ad hoc. Běžní uživatelé postupně získali vyšší role, než potřebovali. Jeden z nich pak omylem smazal celý projektový workspace.

Dopad

  • Projektová dokumentace zmizela na několik dní.
  • Obnova ze zálohy stála čas i peníze.
  • Vedení začalo pochybovat o bezpečnosti nastavení.

Co dělat, když uživatel smaže workspace v OpenText Content Serveru

Prevence a best practices

  1. Obnovit workspace z poslední zálohy.
  2. Provést audit oprávnění.
  3. Dočasně omezit přístup jen na správce.
  4. Informovat tým a nastavit plán obnovy.
  • Zavést princip „nejmenších nutných oprávnění“.
  • Zapnout koš pro obnovu smazaných objektů.
  • Provádět pravidelné revize práv.
  • Dokumentovat každé přidělení vyšší role.

Vychytávky z praxe

  • Export práv do Excelu a čtvrtletní kontrola s byznysem.
  • Alert při hromadném mazání položek.
  • Role-based access místo individuálních oprávnění.
  • Records Management pro ochranu dat.
  • Pravidelná kontrola auditních logů.

Závěr

OpenText Content Server je výkonný nástroj pro správu dokumentů a procesů. Rizikové scénáře nevznikají proto, že by byl nespolehlivý – ale proto, že je komplexní a úzce propojený s byznysem.

Dobrá zpráva je, že každý z popsaných problémů má řešení. Ještě lepší zpráva: správným nastavením, monitoringem a prevencí se jim dá úplně předejít.

Máme za sebou desítky projektů s OpenText Content Serverem, takže víme, jak podobné situace řešit. S námi je nemusíte zvládat sami – rádi vám pomůžeme nastavit systém tak, aby fungoval spolehlivě a bez zbytečných starostí..