 |
 |
 |
|
Deregulacja, transmisja szerokopasmowa, komunikacja z zastosowaniem urządzeń przenośnych, e-biznes, konwergencja usług - to tylko niektóre z elementów będących motorem wszelkich zmian, wyznaczających nowe kierunki rozwoju produktów dla sektora telekomunikacji.
|
|
|
|
|
|
|
|
|
strona główna »
Telekomunikacja » MoRO - Moduł Raportowania Operacyjnego |
|
|
| Telekomunikacja |
| MoRO - Moduł Raportowania Operacyjnego |
|
Platforma raportowa
Moduł Raportowania jest rozwiązaniem o unikalnej budowie, łączącym w sobie elastyczność i wydajność. Moduł jest kluczowym elementem w budowie systemu zarządzania informacją, dedykowanym do analizy i udostępniania dużych wolumenów danych w postaci przejrzystej informacji zarządczej dla kierownictwa. Platforma raportowa pozwala na pobieranie danych z dowolnych lokalizacji (dowolna liczba serwerów produkcyjnych) i źródeł (bazy danych, zbiory z przetwarzania o prostej i złożonej strukturze). Został opracowany w oparciu o technologię SAS z wykorzystaniem HTML i Java Script, COBOL (jeśli rozwiązanie na platformie MainFrame). MoRO stanowi przykład aplikacji wielowarstwowej.
Moduł MoRO działa w oparciu o dane zawarte w zasobach bazy danych systemu operacyjnego, np. systemu billingowego oraz na zasobach rozładowywanych do zbiorów podczas przetwarzania danych. Aby zapewnić właściwą funkcjonalność została zaprojektowana oddzielna baza danych (SAS), która nie ma bezpośredniego powiązania z bazami produkcyjnymi (DB2).
Rozdział baz danych wynika z następujących przyczyn:
- Źródłowa baza danych jest przeznaczona na spełnianie funkcji operacyjnych, jak przyjmowanie transakcji (zmian danych klientów, usług, itp.) oraz masowego rozliczania. Natomiast baza danych MoRO ma strukturę ukierunkowaną na wypełnianie funkcji raportowania oraz funkcji analitycznych.
- Rodzaj obciążenia bazy wynikający z rodzaju pełnionej funkcji. Baza operacyjna obciążana jest cyklicznie zgodnie z harmonogramem przyjmowania danych, rozliczania oraz codziennych działań operacyjnych. Natomiast baza MoRO służy do obsługiwania zapytań, które nie muszą występować regularnie i które mogą powodować duże obciążenie. Nie ma tutaj z kolei funkcji transakcyjnych.
Bazę systemu MoRO określają następujące cechy:
- Zasilanie danymi z bazy źródłowej okresowo, zgodnie z założonym cyklem pojawiania się nowych danych, modyfikacji istniejących, czyli zgodnie z cyklem wszystkich zdarzeń mających wpływ na stan bazy produkcyjnej.
- Stabilność danych, tzn. dane nie są zmieniane.
- Dopasowanie struktury danych do potrzeb analityki i raportowania, nie jest to replika danych źródłowych; są one odpowiednio przekształcone oraz wyselekcjonowane. Zatem baza danych MoRO po ETL nosi cechy Data Mart.
Funkcjonalność:
- ETL – proces pozwalający na wybranie z zawartości tabel DB2 oraz odpowiednich zbiorów systemowych, a następnie przetworzenie do postaci odpowiedniej do wykorzystania w raportach.
Występują tu 3 fazy:
- Ekstrakcja danych z bazy źródłowej
- Transformacja i ładowanie do bazy raportowej (LMORO)
- Agregacja do postaci predefiniowanych raportów
- Prezentacja raportów – platforma raportowa zawiera predefiniowane raporty zgodne z wymaganiami użytkownika dostępne poprzez menu wyboru raportów oraz menu struktury danych i strukturę organizacyjną. Ponadto raporty posiadają parametry wyboru cech ogólnych, jak np. daty cykli raportu i zależne od raportu, jak np. cechy klientów, usług, itp.
- Historia – moduł zapewnia możliwość przechowywania i prezentacji danych przez wybrany okres czasu, co pozwala na dostęp do raportów z okresów poprzednich w niezmienionej postaci.
- Panel administratora – narzędzie, pozwalające na pełną konfigurację uprawnień użytkowników, konstruowanie dostępnych grup raportów w podziale, związanym z ich tematyką, konstruowanie grup użytkowników i raportów (przyspieszenie i ujednolicenie procesu nadawania uprawnień). Wszystkie te funkcje dostępne są bezpośrednio z przeglądarki internetowej, zatem administrator nie jest przywiązany do jednego stanowiska i wszystkie akcje może wykonywać w bezpośrednim kontakcie z użytkownikiem (na końcówce klienta). Dodatkowo panel administratora umożliwia zarządzenie wybranym zakresem danych w taki sposób, że zostaną udostępnione użytkownikom nie po zasileniu platformy, ale dopiero po ich zatwierdzeniu przez administratora – funkcjonalność ta może być nieodzowna w przypadku konieczności weryfikacji procesu biznesowego przed udostępnieniem danych np. na potrzeby Zarządu.
- Diagnostyka – system wyposażony jest w możliwość logowania wszelkiej aktywności, w tym zarówno przebiegu procesu akwizycji danych (do celów analizy wydajności i odnajdywania „wąskich gardeł”), jak i aktywności użytkowników (do celów weryfikacji potrzeb raportowych, blokowania nieużywanych raportów, rozbudowy raportów chętnie wykorzystywanych)
- Harmonogramowanie przetwarzań – w zależności od zastosowanej platformy sprzętowej (obsługa na MainFrame i UNIX) budowa harmonogramu przetwarzania jest stosunkowo prosta, a po implementacji harmonogramu, przetwarzania mogą się odbywać bezobsługowo (np. przetwarzania w cyklu miesięcznym, tygodniowym z uwzględnieniem rodzaju danych i ich zmienności)
- Moduł raportowania „ad hoc” – dane przy przygotowywaniu ich na potrzeby raportów są odpowiednio opisywane i udostępniane użytkownikom bardziej zaawansowanym. Można je łączyć, segregować i tworzyć własne, proste raporty na potrzeby bieżące. Raporty te można zapisywać i udostępniać innym użytkownikom. Wszystkie operacje wykonuje się przy użyciu przeglądarki internetowej, bez żadnych dodatkowych licencji i narzędzi.
- Eksport danych do plików tekstowych o ustalonej strukturze, w szczególności do Excela – każdy z raportów, udostępnionych na platformie raportowej, zapewnia możliwość eksportu danych do pliku tekstowego. Ponadto opracowana została funkcja eksportu danych bezpośrednio do arkusza excelowego w formie zbliżonej do prezentacji w przeglądarce. Funkcjonalność ta jest dostępna w przeglądarce internetowej, pozwala na ewentualne dalsze (specyficzne) przekształcenie / porównanie danych z raportów.
Cechy rozwiązania:
- Rozbudowany system akwizycji danych (ETL), który poza zasilaniem modułu informacyjnego może równocześnie pełnić inne role, np. zasilania hurtowni danych.
- Minimalizacja obciążenia serwerów produkcyjnych osiągnięta poprzez odpowiednią konstrukcję ETL (stąd budowa wielowarstwowa), m.in. dzięki rezygnacji w warstwie ekstrakcji danych z przekształceń.
- Minimalizacja czasu udostępniania raportów on-line na platformie osiągnięta poprzez odpowiednie przygotowanie danych w warstwie agregacji na potrzeby prezentacji danych w trybie on-line na dowolnym poziomie zagłębienia. W procesie agregacji danych można uzyskać spory procent kompresji danych, co bezpośrednio rzutuje na obniżenie wymagań, dotyczących przestrzeni dyskowych, na których składowane są dane do raportów. Przykład: źródła danych do MoRO sięgają 26 TB, podczas gdy po zakończeniu procesu agregacji dane raportowe nie przekraczają 1 TB. Należy podkreślić, że raporty nie są statyczne (tzn. zapewniają możliwość drążenia). Poziom agregacji można dostosować odpowiednio do wydajności serwera WWW i serwera SAS, oraz z uwzględnieniem dostępnych zasobów dyskowych do przechowywania agregatów.
- Spójność i przejrzystość prezentacji danych – wszystkie raporty mają jednolitą postać, jednolity sposób drążenia (w miarę potrzeb i możliwości) i jednolitą obsługę, która jest intuicyjna i praktycznie obsługa platformy przez użytkowników końcowych nie wymaga szkoleń.
- Bezpieczeństwo – dane udostępniane użytkownikom końcowym dostarczane są z wykorzystaniem protokołu SSL.
- Skalowalność i elastyczność – platforma raportowa może być zaimplementowana w kilku wariantach (niekoniecznie z wykorzystaniem wszystkich 5 warstw) na dowolnych systemach operacyjnych, na których jest możliwość instalacji SAS / serwera Apache. Można oczywiście wykorzystać istniejące instalacje. Pod względem funkcjonalnym może obsługiwać od kilku do kilkuset różnych zestawień, udostępnianych dla kilku do kilkuset użytkowników (maksymalnie testowano dostęp 400 użytkowników)
Wymagania systemowe:
- Baza danych: dowolna (dostarczane są wtyczki do istniejących baz produkcyjnych; aktualnie funkcjonujące interfejsy batch związane są z DB2)
- Serwer SAS: zapewniona komunikacja dwukierunkowa via FTP z wszystkimi serwerami danych produkcyjnych, które mają być pobierane do MI 5. SAS posiadający w minimalnej konfiguracji moduły: BaseSAS, SAS/Graph, SAS/IntrNet. Systemy operacyjne: Windows klasy NT, Unix, OS/xxx (obsługiwane przez SAS)
- Serwer WWW: fizycznie może to być ta sama maszyna, co serwer SAS. Zaleca się jednak osobny serwer z systemem operacyjnym Unix / Linux. Musi umożliwiać (lub posiadać) instalację serwera Apache.
Wdrożenia:
Moduł Raportowania został zaimplementowany w Telekomunikacji Polskiej S.A. w oparciu o dane systemu SERAT2. System SERAT2 rozlicza około 10 mln klientów TP z całej Polski, ewidencjonuje kilkanaście milionów urządzeń, usług i pakietów. Bazy produkcyjne łącznie szacowane są na ok. 16 TB danych źródłowych. Natomiast wynikowe dane zagregowane na potrzeby około 80 raportów zajmują ok. 0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| © 2008 ABG S.A. |
|
|
