Ograniczenia i korzyści płynące z użycia Managed Packages

Czym jest Managed Packages i co oznacza dla twojej organizacji?

Managed Packages to sposób na dostarczenie rozwiązań (ustawień, kodu, danych konfiguracyjnych) na konkretną instancję platformy Salesforce. Można to porównać do instalacji aplikacji w systemie operacyjnym naszego komputera. Po instalacji kod nie jest widoczny, aplikacja udostępnia pewne funkcjonalności oraz biblioteki i może być aktualizowana do nowszej wersji.

Najważniejszą kwestią jest fakt, że Managed Packages zostało przygotowane jako narzędzie dla niezależnych dostawców oprogramowania (Independent Software Vendor, ISV). W trosce o dobro klientów na wspomniane „paczki” zostały nałożone pewne ograniczenia. Większość z tych ograniczeń ma na celu chronić klientów ISV przed wszelkimi zmianami, mogącymi spowodować utratę danych i funkcjonalności oraz zgodności z poprzednimi wersjami paczki.

Ten sam mechanizm możemy wykorzystać w celu wewnętrznej propagacji zmian między środowiskami (np. gdy nasza organizacja działa na wielu instancjach Salesforce, a wdrażane rozwiązanie powinno działać tak samo na każdej z nich). Na papierze wszystko wygląda pięknie i zdaje się to być idealnym rozwiązaniem dla organizacji chcących wprowadzić jednolite rozwiązanie dla więcej niż jednej instancji Salesforce. Czy aby na pewno? Ponieważ sens użycia Managed Packages przez ISV jest bezsprzeczny – w tym artykule skupię się na użyciu tego mechanizmu na wewnętrzne potrzeby organizacji.

Ograniczenia związane z użyciem Managed Packages

Decydując się na wykorzystanie tego mechanizmu powinniśmy zdawać sobie sprawę z pewnych kwestii, które mogą być decydującym czynnikiem w procesie decyzyjnym.

  • Podstawowym obostrzeniem są tutaj zmiany w modelu danych. W momencie osadzenia modelu danych w paczce możliwość zmiany typu pola oraz modyfikacji jego właściwości zostaje znacząco ograniczona. W momencie dodania pola do paczki możliwość zmiany atrybutów jak: nazwa API, unikalność oraz External Id stają się niemożliwe. Salesforce przyjmuje zasadę whitelisty i wymienia w dokumentacji listę rzeczy, które możemy zrobić na „zapaczkowanym” modelu danych. Daje tym samym do zrozumienia, że z zasady wszystkie modyfikacje – poza wymienionymi – są niemożliwe.
  • Kolejnym jakże ważnym aspektem wprowadzenia paczek jest zablokowanie wszelkich modyfikacji definicji klas globalnych oraz ich metod – a przez to również web service. Metody nie mogą zostać rozszerzone, by przyjmować dodatkowe parametry, ani usunięte. Oznacza to, że nie ma możliwości wyłączenia raz stworzonego web service. Jedyną możliwością, która pozostaje, jest stworzenie nowej metody/klasy i oznaczenie starej jako „deprecated” oraz usunięcie jej kodu.
  • Bardzo poważnym ograniczeniem administracyjnym jest brak możliwości aktualizacji profili użytkowników. Profile pozwalają na określenie dostępu użytkownika do konkretnych funkcjonalności w systemie oraz dostępu do danych (definicji CRUD na poziomie obiektu). Profile te, podczas instalacji paczki, zostają połączone z już istniejącymi na środowisku. Niestety żadne zmiany ustawień na profilach nie są migrowane wraz z instalacją nowej wersji paczki. Pozostaje nam nanoszenie zmian w profilach ręcznie na każdym środowisku – ilość środowisk możemy zmniejszyć przy użyciu zaawansowanych skryptów.
  • Ponieważ zawartość (głównie kod) paczki jest ukryta, a paczka zarządzana jest na osobnym środowisku developerskim Salesforce rozwój takiej paczki możliwy jest tylko na tym środowisku.
  • Paczka zawsze wykorzystuje najnowszą wersję całego spaczkowanego kodu. Stwarza to ogromne problemy z rozgałęzianiem kodu – choć rozwój wersji z poprawkami jest częściowo wspierany. Jednoczesna praca nad funkcjonalnościami z różnych wersji oprogramowania jest niemożliwa, a wydanie nowej wersji paczki wymaga ukończenia wszelkich funkcjonalności tej paczki będących w trakcie rozwoju.
  • Dodatkowo środowisko developerskie, na którym rozwijana jest paczka ma dostępne tylko dwie licencje dla użytkowników. Oznacza to, że albo aplikację rozwijały będą maksymalnie dwie osoby, albo konta użytkowników będą współdzielone, co utrudni nam śledzenie zmian.
  • Ostatnim ograniczeniem, o którym chciałem napisać, jest poważne ograniczenie w automatyzacji operacji. Otóż aktualnie jedyną możliwością na stworzenie nowej wersji paczki jest zrobienie tego ręcznie z poziomu interfejsu użytkownika, wejściu na odpowiednie środowisko. Oznacza to, że wszelka automatyzacja publikacji nowych wersji (również testowych) jest niemożliwa. Używając Managed Package możemy zapomnieć o Continuous Integration.

Korzyści wynikające z użycia Managed Packages

Korzyści z użycia „paczek” jest wiele. Niestety większość z nich dotyczy nas jedynie, gdy jesteśmy ISV. Natomiast tracą na znaczeniu, gdy rozwiązanie jest przygotowywane na wewnętrzne potrzeby organizacji.

  • Do głównych korzyści zaliczyłbym łatwość instalacji i aktualizacji. Trzeba jednak pamiętać, że każda z tych korzyści okupiona jest dodatkowym kosztem po stronie programistów. Dopiero przy wielu instancjach bilans kosztów wychodzi dodatni.
  • Dodatkowymi korzyściami z użycia paczek jest hermetyzacja rozwiązania oraz wbudowana obsługa wersjonowania komponentów dostępnych przez API. Hermetyzacja zapewnia zgodność z firmowymi standardami dając jednocześnie wolność w implementacji rozszerzeń oraz dostosowywania rozwiązania w ramach instancji zgodnie z wymaganiami biznesowymi bądź regulacjami prawnymi.
  • Wbudowana obsługa wersjonowania komponentów dostępnych przez API zapewnia nam, że zbudowane integracje nie przestaną działać wraz z wprowadzeniem nowej wersji „paczki” oraz w awaryjnej sytuacji zapewnią możliwość użycia starszej – działającej – wersji paczki.

Kto powinien korzystać z Managed Packages

Ze względu na specyfikę i przeznaczenie, bez dobrej znajomości Managed Package, podczas wdrożenia na wewnętrzne potrzeby organizacji łatwo jest wpaść w pułapkę. Naprawa rozwiązania staje się kosztowna niezależnie od kierunku, który obierzemy później. Kluczowym elementem poprawnego wdrożenia rozwiązania w oparciu o paczki jest wiedza odnośnie implikacji wykorzystania tego mechanizmu – jego ograniczeń oraz zalet. Ze względu na konsekwencje, które niesie ze sobą użycie Managed Package, rozwiązanie to powinniśmy rozważać tylko wówczas gdy jesteśmy pewni, że jest to dobry wybór.

Manage Package mogę polecić organizacjom, które planują wprowadzić jednolite rozwiązanie na wielu instancjach platformy Salesforce. Do modelowania rozwiązania sugeruję zaangażowanie doświadczonego architekta (ze znajomością Managed Package), który powinien nadzorować cały etap wdrożenia. Pozwoli to uniknąć przykrych niespodzianek podczas utrzymania systemu.

Zdecydowanie odradzam Managed Package firmom, które chcą je wdrożyć jedynie w celu organizacji kodu. Dotyczy to również firm nieposiadających „dojrzałego” modelu danych na szczeblu organizacji lub szczegółowej architektury rozwiązania.

 

Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on LinkedIn17

Podobne wpisy

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *