Narzędzia na dodatek

Kolejna wersja pakietu Visual Studio Tools For Office (VSTO) zawiera projektanta dla pasków Ribbon, służącego do tworzenia zakładek zadań i innych elementów interfejsu wszystkich składników pakietu Office 12. Tworzone dodatki są wczytywane przez runtime VSTO, co pozwala unikać pewnych problemów związanych z współdzieleniem AppDomain i CAS. VSTO zawiera specjalne elementy upraszczające tworzenie dokumentów po stronie serwera, co będzie ułatwieniem dla tych, którzy nie chcą bezpośrednio pracować z XPS czy XML.

Łatwo można także tworzyć reguły uaktualniające dodatki, czy wręcz instalujące nowe komponenty na firmowych komputerach. Podsumowując, dodatek napisany w .Net zachowuje się tak, jak pełnoprawny składnik Office 12. Dzięki temu prostsze stało się także śledzenie wykonywania programu, np. wyjątek może być przechwycony przez IDE.

Dzięki runtime można manipulować treścią XPS bez uruchamiania konkretnej aplikacji Office, co sprawia, że tego typu operacje są znacznie szybsze. Można więc będzie wygodnie wykonać masowe konwersje z/na format Office 2003 - bez utraty formatowania itp. Tworząc dodatek do Office 12, można określić tzw. kontrolkę dokumentu. Jest to element zawierający kod, który określa, czy dane są prawidłowe, lub też sugerujący wypełnienie na podstawie zewnętrznego źródła.

Oprócz VSTO Microsoft ogłosił na PDC, że udostępni specjalną wersję Visual Studio Tools for Applications umożliwiającą budowę rozwiązań. To duża zmiana - dotychczas dostępny był jedynie VBA - motor, który można było osadzać we własnych aplikacjach (korzystał z tego np. AutoCad czy Corel). Teraz do automatyzacji aplikacji można będzie używać .Net - a w ramach tego pakietu licencjobiorca otrzyma też redystrybuowalne środowisko IDE i runtime - prawdopodobnie będą one takie same jak te, które wchodzą w skład VSTO.

Do wizualizacji danych po stronie klienta może być także wykorzystane Visio 12. Można podłączyć go do źródła danych i określić mapowanie pomiędzy polami a kształtami, łącznikami, kolorami obiektów itp. W momencie dodawania nowych elementów mogą pojawiać się dodatkowe kształty na obszarze projektanta. Tak naprawdę jest to mechanizm o potencjalnie dużych możliwościach - pozwala np. prosto zbudować strony z dynamicznie odświeżającą się zawartością, ale przynajmniej na razie nie jest intuicyjny w użyciu.

Excel na serwerze

Excel już dawno przestał być tylko "arkuszem" kalkulacyjnym - coraz więcej wiedzy przedsiębiorstw znajduje się w rozmaitych skoroszytach - czy to procedury wyliczające ubezpieczenie, prowizję, czy też szkice budżetów lub analiz finansowych. Dostępnych jest też kilka rozwiązań, które pozwalają przenieść "logikę" z Excela do własnej aplikacji i uruchamiają arkusz bez potrzeby uruchamiania Excela. To jednak wciąż traktowanie arkusza jako elementu aplikacji klienckiej, co prowadzi do powstawania w firmie "wielu wersji prawdy".

Microsoft w Office 12 oferuje specjalny serwer przetwarzający skoroszyty Excela. Dostęp jest możliwy za pośrednictwem WWW - albo w formie kontrolki dla serwera SharePoint, albo prostej witryny HTML dostępnej za pośrednictwem odpowiednich usług Web. Jest to de facto serwer aplikacyjny bazujący na Excelu. Przechowuje stan, odświeża dane itp. - może nawet być skalowany i uruchamiany na kilku maszynach. Niestety, pierwsza wersja "usług Excela ma kilka ograniczeń. Nie ma pełnego modelu obiektowego Excela, brak obsługi makr/VBA (choć jest obsługa samych formuł). Nie ma też możliwości, by po stronie serwera wczytać dodatek, choć (podobno) mają się dać wczytywać biblioteki formuł.

Tak naprawdę "Excel Server" to rozwiązanie przeznaczone do tworzenia kilku typów rozwiązań. Pierwsze, to takie, gdzie trzeba wykorzystać logikę zakodowaną w Excelu do sterowania inną aplikacją. Udostępnienie usługi Web pozwala bez problemu skorzystać z np. pewnych wyliczeń na podstawie danych znajdujących się w konkretnych komórkach arkusza na serwerze. Zaleta jest taka, że łatwo można zmienić sposób wyliczeń - modyfikując formuły na pliku Excela na serwerze. Należy tu podkreślić, że w takim przypadku - podczas pracy aplikacji - Excel jest chroniony na serwerze, nie jest łatwo dostępny dla klienta - pełni rolę "czarnej skrzynki".

Drugi scenariusz zakłada, że sparametryzowany arkusz wykorzystywany jest np. jako "dashboard" z informacjami pokazywanymi użytkownikom jako kontrolka ASP .Net 2.0/Windows Sharepoint Services (WSS). Ot, taki interaktywny arkusz dostępny dla użytkowników za pośrednictwem przeglądarki internetowej. Na razie wiadomo, że taki arkusz można uaktualniać, ale jedynie przy użyciu odpowiedniego API. Czy ostatecznie będzie to współdzielony na serwerze arkusz nadający się do współbieżnej edycji przez wielu użytkowników - nie wiadomo.

Nowy świat InfoPath

Jednym z zadań każdego systemu jest gromadzenie danych wprowadzanych przez użytkownika, np. w celu zainicjowania pewnego procesu biznesowego, zasilenia bazy danych itp. We wszystkich takich przypadkach programista staje przed zadaniem stworzenia odpowiedniego zastawu formatek - nie jest to zajęcie pasjonujące, ale z punktu widzenia użytkownika bardzo ważne. Niewygodna formatka powoduje realne straty (dłuższy czas pracy itp.). W Office 2003 wprowadzono narzędzie InfoPath, przeznaczone do tworzenia formatek, złożonych z pól, list, siatek itp., które potem są zapisywane do dokumentu XML lub bazy danych. W Office 12 ten mechanizm zostanie znacznie rozszerzony.

Formularze InfoPath mogą być dostępne na serwerze za pośrednictwem przeglądarki, telefonu komórkowego itp. Bez względu na sposób dostępu projektuje się je tylko raz - z uwzględnieniem formatowania warunkowego, walidacji, zarządzanego kodu formatek czy definicji źródeł danych. Wprowadzony model obiektowy różni się od tego, który był dostępny w Office 2003, ale może być używany z poziomu "czystego" MSIL. Starszy kod jest prawie w całości uaktualniany - jednak są pewne wyjątki - np. używanie zmiennych statycznych w formularzach bazujących na serwerze jest niemożliwe (brak obsługi mechanizmu sesji).

Designer InfoPath ostrzeże, które elementy nie będą dostępne w przypadku osadzenia na serwerze. Jeżeli jednak po kliknięciu na formularz przeglądarce uda się otworzyć smartclient (czyli InfoPath), to aplikacja uzyska kilka unikalnych możliwości - może stosować mechanizmy IRM/RMS, skrypty, ActiveX, Master-detail czy tryb offline. Dużo elementów zmienia się w związku z obiegiem danych generowanych przez InfoPath. Formularz może być wysłany do usługi Web, formularza WWW (metoda post), biblioteki (listy) SharePoint/WSS, adresu poczty elektronicznej, dowolnej bazy z dostępem ADO itp. Analogiczne elementy mogą być także źródłem danych (np. do wypełniania list wyboru).

Do tworzenia procesu obiegu można wykorzystać pocztę elektroniczną. Jeżeli formularz zostanie wysłany pocztą, użytkownik otworzy go w Outlooku i np. wysyłając odpowiedź spowoduje zapisanie wyniku w liście WSS. Wykorzystując mechanizm workflow wbudowany w nową wersję SharePoint Server, można łatwo generować obiekty dokumentów, o czym niżej.

W rytmie workflow

W nowym SPS pojawi się specjalny komponent do zarządzania przepływem dokumentów - Windows Workflow Foundation (WWF). Komponent ten będzie także dostępny do osadzania we własnych aplikacjach, ale SPS jest serwerem, w którym ten komponent jest uruchamiany w ramach Office Server - oprogramowany dodatkowo pewnymi standardowymi rozwiązaniami.

Na początku warto wyjaśnić kilka podstawowych pojęć. W WWF workflow składa się z pewnego zestawu czynności połączonych grafem przepływu. Graf ten definiuje sposób obsługi standardowego dokumentu w firmie. Czynności definiują to, co ma wykonać system komputerowy albo użytkownik. Aby to wszystko działało, konieczny jest proces - host, który śledzi stany dokumentów i czynności, pozwala lub zabrania kontynuować operacje itp. W przypadku Office taką rolę pełni SharePoint Portal Server. Standardowe działania obejmują m.in. zapisanie historii, utworzenie zadania, skasowanie zadania, aktualizację elementu w Outlook, publikację dokumentu na WWW, wysłanie poczty, sprawdzenie uprawnień, żądanie "większych" uprawnień od przełożonego, dodanie zadania "uzupełnij ankietę".

Oto prosty przykład działania WWF. W ramach jednego procesu można wygenerować dokument w Word, zgłosić zadanie (zatwierdzić dokument) jako "zadanie" w programie Outlook przełożonego. Następnie, w momencie zatwierdzenia przez niego dokumentu, można poprosić o wypełnienie formularza InfoPath, który zostanie zapisany do listy SharePoint z pełną informacją o tym, kto i kiedy pracował nad daną operacją (śledzenie). Co najważniejsze, żeby to osiągnąć, wystarczy użyć interfejsu administracyjnego - nie trzeba nic programować.

Projektowanie zadań przepływu można wykonać z poziomu FrontPage 12. Można tam zaprojektować formatki do rozpoczęcia przepływu, zatwierdzenia etapu itp. Większość operacji wykonuje się przy użyciu kreatora, wybierając akcje i określając zmiany stanu dokumentu. Warto dodać, że Visual Studio pozwala dodatkowo projektować nowe czynności składające się na workflow (używając FrontPage można tylko stosować już zdefiniowane). Mamy także większą kontrolę nad całym procesem.

SharePoint Portal Server 12 zawiera rozbudowany mechanizm przechowywania dokumentów - tak naprawdę można na nim zbudować całkiem dojrzały system do zarządzania i archiwizacji dokumentów. Pozwala m.in. na wersjonowanie dokumentów - i to zarówno Worda, jak i np. dokumentów powstających w wyniku wypełnienia listy. Można określić, ile wersji "wstecz" będzie przechowywanych. W zależności od uprawnień można też kontrolować, co będzie publikowane. Pełna historia pozwala na audyt zmian. Ciekawostka: w SharePoint Portal Server 12 dostępny jest "kosz".

Istnieje możliwość przypisywania uprawnień nie tylko do pojemników/list, ale też do poszczególnych elementów. Dowolne właściwości można dodawać do folderów i elementów - a także (w przypadku dokumentów Office) mapować je na metadane pliku. Można również zastosować dodatkowe formularze (np. metryka dokumentu projektowego) i potem pokazać w liście określone pola jako dodatkowe kolumny (bardzo wygodne!). Programowo jest możliwość reagowania na zmiany określonych pól, niezależnie od tego, czy pole dokumentu/listy będzie wykorzystane w ramach workflow. Dużo elementów, np. sposób prezentacji, można powiązać z określonym zestawem cech, np. samodzielnie zdefiniowanych pól listy/elementu. Programista może też dodać "własny" typ pola, zawierający np. niestandardową walidację. Warto też dodać, że proces workflow może zależeć od typu dokumentu i typów/atrybutów pól.

Więcej nahttps://www.computerworld.pl