Nowości i zmiany na platformie ServiceNow w wersji Tokyo

Sii
BlogerSii
Nowości i zmiany na platformie ServiceNow w wersji Tokyo

ServiceNow opublikował nową wersję NowPlatform o nazwie Tokyo, która obiecuje wspomóc firmy w stawianiu czoła nowym wyzwaniom biznesowym wynikającym z trudnych czasów gospodarczych. Tokyo zostało stworzone z myślą o firmach, które rozumieją korzyści płynące z cyfrowej transformacji. Platforma pomoże zwiększyć automatyzację pracy i bezpieczeństwo oraz zapewni lepsze doświadczenia dla pracowników i klientów.

Poniższy artykuł podsumuje zmiany, które wprowadziła wersja Tokyo i dlaczego warto się im przyjrzeć.

Zmiany w JavaScript engine

Najważniejszą zmianą, która zaszła w najnowszej wersji Tokyo, jest zmiana silnika JavaScript z ECMAScript5 na ECMAScript 2021 (ES12) JavaScript. Na platformie ServiceNow ECMAScript 2021 (ES12) nie została jeszcze wprowadzona dla aplikacji i skryptów globalnych, obecnie jest jedynie dostępna w zakresie scoped. Nowy standard pozwala na wykorzystanie na instancjach następujących funkcji:

default function parameters,
const declaration,
let declaration,
arrow functions,
class declarations,
for-of loops,
rest parameters,
template literals,
destructuring,
map set,
optional chaining operator.

Ryc. 1 ECMAScript 2021 (ES12) JavaScript

Nowy typ adresu IP

Jedną z nowości w wersji Tokyo jest wsparcie migracji adresów IP, przechowywanych jako ciągi znaków, do nowego typu adresu IP Address (Validated IPV4, IPV6). Nowy typ adresu IP będzie przechowywany zgodnie z obowiązującymi normami adresów IPv4 oraz IPv6.

Dane są formatowane zgodnie z ip_data_control i mogą mieć ustawioną jedną z czterech wartości:

Canonical – adresy IP są sprawdzane i kanonizowane przed wprowadzeniem do bazy danych. Wszelkie niepoprawne adresy IP są odrzucane.
Canonicalize_when_possible – prawidłowe adresy IP są kanonizowane przed uzyskaniem dostępu do bazy danych, ale również nieprawidłowe adresy IP mogą uzyskać dostęp bez żadnych zmian.
Expanded – adresy IP są sprawdzane i przechowywane w formie rozszerzonej, a niepoprawne adresy IP są odrzucane.
None – brak sprawdzenia typu, nie powinno być używane zbyt często, tylko w nagłych wypadkach, ponieważ wartość ta odwraca nowy typ adresu IP na stary typ łańcucha znaków.

Język awaryjny lokalizacji systemu

Kolejną nowością jest język awaryjny pomagający w sytuacjach, gdy UI nie zostanie przetłumaczone na język potrzebny użytkownikowi. Do ustawienia języka awaryjnego niezbędna jest rola administratora, ale nie ma potrzeby dodawania własnych tłumaczeń do interfejsu użytkownika. Użytkownicy otrzymają najbardziej odpowiednie dla nich tłumaczenia, a jeśli któreś z nich nie będzie dostępne, wówczas sesja instancji będzie używała języka angielskiego.

Administratorzy mogą ustawić języki awaryjne w tabeli Languages (sys_language), jednak język angielski nie jest dostępną opcją wyboru, gdyż jest to język domyślny. Jeśli język awaryjny nie jest nam potrzebny, a jedynym preferowanym językiem na instancji jest język angielski, właściwość glide_i18n.language_fallback_enabled powinniśmy ustawić jako false.

Zapobieganie manipulacjom w logach systemowych

Równie ciekawym dodatkiem, który pojawił się w wersji Tokyo, jest możliwość skonfigurowania reguł zapobiegających manipulowaniu logami systemowymi. Od obecnej wersji, wszystkie zmiany bądź próby zmian na tabelach sys_log będą widoczne.

Aby uruchomić ochronę należy aktywować plugin com.glide.protected_tables. W chwili obecnej reguły ochronne dostępne są dla następujących tabel oraz ich rozszerzeń: syslog, syslog_transaction, sys_outbound_http_log, sysevent, sys_audit, sys_push_notification, protected_table_configuration.

Po aktywacji pluginu, wszelkie próby usunięcia lub zmiany logów ze wspomnianych wyżej tabel będą widoczne jako zapisy logów w tabeli protected_table_log. Można wybrać, czy chcemy blokować modyfikacje i logować próby, nie blokować modyfikacji, ale logować próby, czy też chcemy blokować modyfikacje bez logowanych prób manipulacji na logach.

Bezpieczne usuwanie i aktualizowanie rekordów

Dzięki nowej wersji Tokyo możliwe jest również bezpieczne usuwanie lub aktualizowanie rekordów. Do usunięcia rekordów potrzebna jest delete job. Po jej utworzeniu, ale jeszcze przed wykonaniem zadania, możemy podejrzeć wszystkie rekordy, na których scheduled job będzie pracować. W wersji Tokyo, nawet po zakończeniu scheduled job, możemy użyć roll back i przywrócić usunięte rekordy.

Usuwanie większej liczby rekordów jest również możliwe dzięki table cleaner. Table cleaner jest rodzajem zaplanowanego zadania, które pomaga usunąć wszystkie stare rekordy i utrzymać ilość pozostałych na stałym, niezbyt wysokim poziomie.

Table cleaner uruchamia się raz na godzinę i usuwa wszystkie przestarzałe, nieważne i niepotrzebne rekordy. Rekordy są usuwane podczas dwudziestominutowych sesji, liczba usuniętych rekordów może się różnić w zależności od zapytania. Zaplanowane zadania nie są odpowiednie dla tabel korzystających z rozszerzeń lub rotacji. Opcja ta nie może być użyta dla tabel, które są skonfigurowane do korzystania z rozszerzenia lub rotacji tabel.

W wersji Tokyo możliwa jest też masowa aktualizacja rekordów bez konieczności skryptowania. Aby z niej skorzystać, należy utworzyć zadanie aktualizacji. By zapobiec zablokowaniu tabeli podczas wykonywania zadania, powinniśmy dodać kilka warunków ograniczających aktualizację rekordów. Również tu można sprawdzić rekordy, na których zamierzamy działać przed aktualizacją i przywrócić je przez roll-back w razie potrzeby, jednak do wykonania roll-backa niezbędna jest rola administratora.

Nowy scoped cache API

W wersji Tokyo otrzymaliśmy również ScopedCacheManager API, który gwarantuje szybszy dostęp do danych przechowywanych w pamięci. Aby pobrać, ustawić lub opróżnić cache, admin powinien zainstalować com.glide.scopedcache plugin, które musi zostać wybrane przed użyciem cache lub cache pair. Na razie możemy używać table pair cache, table row pair cache, table column pair cache oraz table column and row pair cache.

ScopedCacheManager API daje nam kilka benefitów, takich jak możliwość korzystania z danych w pamięci podręcznej poza cyklem transakcji, czy buforowanie wyników ważnych operacji w celu ich szybkiego wykorzystania w przyszłości. Możemy również cashe’ować łańcuchy znaków, aby mieć dostęp do nich lub aplikacji, które mogą być czyszczone w zależności od zmian w tabelach bazowych.

Wsparcie lokalizacji systemu

Kolejną zmianą wprowadzoną przez wersję Tokyo jest wsparcie lokalizacji systemu. Lokalizacja pomaga komfortowo korzystać z jednej instancji dla użytkowników z różnych części świata. Informacje takie jak czas, data czy waluta mogą być sprecyzowane i zależne od lokalizacji. ServiceNow obsługuje wiele języków domyślnie, ale możliwe jest także zapewnienie własnych tłumaczeń, zwłaszcza w przypadku niestandardowych modyfikacji lub aplikacji.

Pasek boczny

Dzięki wersji Tokyo, możemy użyć bocznego paska w konwersacyjnych interfejsach. Dzięki niemu, agenci mogą tworzyć dyskusje z innymi agentami w czasie rzeczywistym. Konwersacje mogą być oparte o rekordy z tablicy 'task’ lub 'interaction’. Przy obecnej wersji instancji, możliwe jest stworzenie jednej dyskusji dla jednego rekordu.

Boczny pasek jest dostępny w następujących obszarach roboczych:

CSM Configurable Workspace,
CSM Manager Workspace,
HR Agent Workspace,
ITSM Manager Workspace,
Vendor Management Workspace.

Podsumowanie

Mam nadzieję, że liczne zmiany i ulepszenia wprowadzone na platformie ServiceNow w wersji Tokyo wpłyną na łatwość i efektywność wykorzystania narzędzia w codziennej pracy. Zachęcam do ich wypróbowania.