XER (Primavera)

XER to format wymiany danych programu Primavera, wykorzystywanego do zarządzania dużymi projektami.

Struktura wewnętrzna i specyfikacja formatu wymiany danych Primavera

Format XER stanowi autorski, tekstowy standard zapisu danych wyeksportowanych z oprogramowania Primavera P6, stworzonego pierwotnie przez firmę Primavera Systems, a obecnie rozwijanego przez korporację Oracle. Głównym zadaniem tego formatu jest umożliwienie przenoszenia kompletnych harmonogramów, struktur podziału pracy (WBS), przypisań zasobów oraz powiązań między zadaniami pomiędzy niezależnymi instancjami baz danych. W przeciwieństwie do zamkniętych plików binarnych, XER jest zrzutem tabelarycznym z relacyjnej bazy danych (najczęściej Oracle Database, Microsoft SQL Server lub lokalnej bazy SQLite w wersjach jednostanowiskowych), zapisanym w formie czystego tekstu (plain text). Z technicznego punktu widzenia plik XER charakteryzuje się precyzyjną, blokową budową. Każdy blok danych rozpoczyna się od zdefiniowania tabeli, co w kodzie pliku oznaczane jest prefiksem procentowym, na przykład %T. Następnie następuje definicja poszczególnych pól wewnątrz danej tabeli, sygnalizowana prefiksem %F. Właściwe wiersze z danymi, odpowiadające rekordom w bazie relacyjnej, poprzedzone są z kolei prefiksem %R. Zastosowanie takiej struktury wymusza rygorystyczne przestrzeganie integralności relacyjnej systemu. Kompletny plik zawiera zrzuty kilkudziesięciu różnych tabel, począwszy od danych podstawowych projektu (tabela PROJ), przez listę zadań (TASK), powiązania logiczne między nimi (TASKPRED), aż po słowniki globalne, takie jak struktury organizacyjne (OBS) czy kody projektów. Taka architektura pliku sprawia, że jest on stosunkowo łatwy do odczytania dla prostych parserów i skryptów tekstowych. Jednocześnie, ze względu na brak natywnej walidacji schematu, błędy w strukturze XER mogą prowadzić do uszkodzeń w relacyjnej strukturze danych podczas próby importu do docelowej bazy danych.

Analiza mechaniki transferu i zestawienie ze standardem XML

Wdrożenie formatu XER podyktowane było koniecznością sprawnej wymiany informacji w środowiskach inżynieryjnych, w których poszczególni wykonawcy i podwykonawcy realizujący inwestycję korzystają z własnych, odizolowanych instalacji systemu Primavera. Ze względu na swoją architekturę, mechanizm importu i eksportu XER działa na zasadzie bezpośredniego mapowania rekordów. W praktyce oznacza to, że aplikacja czytająca plik przetwarza poszczególne wiersze %R i wprowadza je bezpośrednio do swoich tabel za pośrednictwem warstwy logiki biznesowej oprogramowania. Chociaż jest to proces wydajny obliczeniowo, niesie ze sobą ryzyko nadpisania danych na poziomie globalnym. W systemie Primavera wiele słowników, takich jak zasoby (Resources), kalendarze (Calendars) czy kody (Project Codes), posiada zasięg ogólnofirmowy (Enterprise Data). Import pliku XER zawierającego modyfikacje w tych obszarach skutkuje zmianą definicji słownikowych we wszystkich innych projektach hostowanych w tej samej bazie docelowej. Aby ograniczyć to zagrożenie, administratorzy muszą stosować restrykcyjne procedury mapowania podczas importu lub korzystać z narzędzi firm trzecich do autoryzacji poszczególnych rekordów przed ich wczytaniem. Alternatywą zaimplementowaną przez producenta w nowszych wersjach systemu jest format Primavera XML. Zastosowanie standardu XML pozwala na weryfikację strukturalną przy użyciu schematów XSD oraz zapewnia wyższą granulację przy określaniu, które pule danych globalnych mają zostać zaktualizowane, a które całkowicie pominięte w procesie wczytywania harmonogramu. Pomimo obiektywnych przewag formatu XML w zakresie bezpieczeństwa warstwy aplikacyjnej, XER pozostaje w powszechnym użyciu w branży. Wynika to z jego długiej historii, kompatybilności wstecznej z bardzo starymi wersjami oprogramowania (w tym z linią Primavera P3e/c) oraz mniejszego zapotrzebowania na przestrzeń dyskową, wynikającego z braku ciężkiego narzutu znaczników, który jest cechą charakterystyczną plików XML.

Znajomość specyfikacji pliku XER jest przydatna, ponieważ pliki te bywają często modyfikowane bezpośrednio w edytorach tekstu w celu szybkiej zmiany identyfikatorów projektów lub masowego podmieniania kalendarzy bez konieczności uruchamiania pełnego środowiska serwerowego. Działania te opierają się na fakcie, że format korzysta ze standardowego kodowania ASCII lub UTF-8, a poszczególne wartości w wierszach oddzielane są znakiem tabulacji. Taka ingerencja wymaga jednak od operatora dokładnej znajomości relacji kluczy głównych i obcych w architekturze wewnętrznej oprogramowania Primavera. Ręczna modyfikacja klucza głównego (na przykład pola `proj_id`) w pojedynczej tabeli, bez jednoczesnego zaktualizowania wszystkich tabel relacyjnie z nią powiązanych (na przykład definicji wydatków czy przydziałów materiałowych), doprowadzi do natychmiastowego zerwania spójności danych docelowych.

Mechanizmy powstawania błędów, anomalie tabelaryczne i niezgodności

Najczęściej występujące komplikacje techniczne podczas pracy z rozszerzeniem XER wynikają z braku mechanizmu kompatybilności w przód (forward compatibility). Plik wyeksportowany z nowszej wersji systemu Primavera P6, na przykład z rewizji oprogramowania 22.12, posiada w swoim nagłówku procentowym twardą deklarację wersji eksportu. Próba załadowania takiego pakietu do starszej instalacji serwerowej (na przykład wersji 16.2) wygeneruje błąd analizatora syntaktycznego na długo przed podjęciem przez system jakichkolwiek prób zapisu w tabelach SQL. Często stosowanym w branży inżynierskiej obejściem tego ograniczenia jest manualna edycja pierwszego wiersza pliku XER w notatniku w celu obniżenia zadeklarowanej wersji. Operacja ta udaje się tylko pod warunkiem, że nowsza wersja systemu nie umieściła w pliku dodatkowych, wprowadzonych niedawno tabel lub kolumn, z których parsowaniem starszy schemat relacyjny sobie nie poradzi.

Inną udokumentowaną historycznie anomalią tego formatu był błąd tabeli POBS (Perform Object Based System). W wielu starszych instalacjach oprogramowania P6 usterka procesu kompilacji eksportu powodowała dołączanie tabeli POBS do wynikowych plików wymiany, nawet wtedy, gdy transfer tych danych nie był celem użytkownika. Każdorazowy proces importu i ponownego eksportu pliku XER multiplikował zduplikowane wiersze bazy, prowadząc do zjawiska niekontrolowanego zwiększania się objętości danych. Powodowało to opóźnienia w działaniu platformy, ponieważ pliki z harmonogramami rozrastały się z kilkudziesięciu kilobajtów do rozmiarów liczonych w setkach megabajtów. Problem wymusił powszechne wdrożenie zewnętrznych skryptów czyszczących, które masowo usuwały blok %T POBS z kodu wynikowego. Często notuje się także komplikacje z nieprawidłowym renderowaniem systemów kodowania znaków. Jeśli eksport pliku XER zostanie przeprowadzony na stanowisku z systemem operacyjnym Windows skonfigurowanym z określonym regionalnym zestawem znaków (locale), a odczyt nastąpi na maszynie o innej konfiguracji kodowania, znaki diakrytyczne występujące w opisach zadań i nazwach firm mogą ulec trwałej korupcji. Program ładujący zamieni nierozpoznane sekwencje bajtów na znaki zapytania lub symbole błędów tekstowych, co zmusza analityków do ręcznej konwersji standardu kodowania pliku jeszcze przed zainicjowaniem transferu sieciowego.

Utrata nośników projektowych i interwencja serwisu sprzętowego

Przetwarzanie rozbudowanych harmonogramów budowlanych lub informatycznych za pomocą oprogramowania Primavera P6 wymaga infrastruktury sprzętowo-sieciowej opartej na scentralizowanych węzłach bazodanowych. Ewentualne wsparcie techniczne w sprawach uszkodzonych tabel bazy danych Oracle czy błędów samego oprogramowania Primavera należy do kompetencji administratorów tych systemów i specjalistów baz danych. Jako punkt napraw sprzętu, Warszawskie Pogotowie Komputerowe nie zajmuje się odbudową uszkodzonych logicznie plików architektury XER ani błędami samej aplikacji projektowej. Istnieją jednak sytuacje fizycznych awarii sprzętowych, w których nasze kompetencje okazują się przydatne ze względu na lokalny model pracy niektórych planistów.

Pliki w formacie XER są często zapisywane w pamięci lokalnych stacji roboczych – na wbudowanych dyskach SSD i HDD służbowych laptopów. Odbywa się to zazwyczaj w celach archiwizacyjnych, w ramach pracy w środowisku autonomicznym (Primavera P6 Professional Standalone) lub przed przekazaniem pakietu za pośrednictwem lokalnych nośników USB. Jeśli w wyniku uszkodzenia mechanicznego lub elektrycznego sprzętu komputerowego – takiego jak zwarcie na poziomie warstw laminatu płyty głównej laptopa, zalanie klawiatury i układów zasilania, czy awaria elektroniki nośnika pamięci – dostęp do sprzętu staje się niemożliwy, użytkownik traci fizyczny dostęp do swoich projektów. W tego typu usterkach interwencja serwisu obejmuje precyzyjną diagnostykę płyty głównej, wylutowanie niesprawnych przetwornic i układów sterujących sekcją zasilania, a także próbę bezpiecznego wyizolowania modułu pamięci. Celem działań warsztatowych jest uruchomienie nośnika w środowisku diagnostycznym, przy zastosowaniu sprzętowych blokerów zapisu (write blocker). Pozwala to na stworzenie pełnej, binarnej kopii posektorowej uszkodzonego talerza lub kości flash i przeprowadzenie z niej ekstrakcji konkretnych rozszerzeń plików, w tym `.xer`. Wprawdzie obecnie, z uwagi na powszechność technologii półprzewodnikowej (Solid State Drive), zgłoszenia dotyczące mechanicznych uszkodzeń starego typu dysków talerzowych stały się rzadkością w naszym serwisie, to jednak długi cykl życia sprzętu wykorzystywanego w mniejszych firmach inżynieryjnych sprawia, że takie procesy odzyskiwania danych wciąż są realizowane w naszym laboratorium. Końcowym etapem obsługi zlecenia jest zabezpieczenie odzyskanych plików źródłowych na nowym, sprawnym nośniku pamięci masowej, co umożliwia klientowi wczytanie danych z lokalnego pliku XER na kolejnym, sprawnym komputerze służbowym.