Kategoria ogólna

Rozdział zawiera szczegółowy opis bloczków z kategorii ogólnej.

Bloczki zostały umieszczone po lewej stronie okna w menu Przybornik.

Do kategorii ogólnej należą bloczki:

Uruchom algorytm

Bloczek Uruchom algorytm służy do uruchamiania na strukturze elementu algorytmu. Wyniki są umieszczane w tej samej strukturze.

W parametrach bloczka należy podać ścieżkę do algorytmu / tabeli do wywołania, a na zakładce Szczegóły wskaż korzeń wywołania (Wybierz korzeń) oraz zmapuj parametry wejściowe algorytmu/tabeli. - Struktura algorytmu podpowiadana jest w formie wyszarzonego rekordu i pól danych.

Możesz dodać pola do schematu i wyznaczyć im wartość lub przeciągnij pola ze schematu danych na wyszarzone pola struktury danych algorytmu. Z menu kontekstowego wybierz Ustaw źródło.

Wskazany element zostanie wywołany tyle razy, ile fizycznie rekordów znajduje się w punkcie wywołania w momencie przetwarzania, a wyniki wywołania zostaną wstawione pod punktem wywołania i będą dostępne w następnym bloczku. Wynik wyliczeń algorytmu dostępny jest też na schemacie danych.

W parametrach bloczka można też włączyć dodanie tekstowych pól technicznych przeznaczonych na wejściowy i wyjściowy XML przekazywany do/z algorytmu.
Pozwala to na szybką diagnostykę błędnych uruchomień czy kopiowanie danych z przetwarzania testowego do testów jednostkowych algorytmów.

Utworzenie dokumentu

Bloczek Utworzenie dokumentu umożliwia generowanie dokumentów w formatach DOCX i PDF na podstawie szablonu przygotowanego w edytorze Word z zainstalowaną funkcjonalnością generowania dokumentów - więcej patrz: Generowanie dokumentów

Bloczek wymaga skonfigurowania:

korzenia danych wejściowych, czyli rekordu w strukturze danych, który będzie zawierał dane źródłowe do dokumentu (po wejściu w szczegóły bloczka i zaznaczeniu rekordu należy wybrać podświetlony na żółto przycisk Wybierz korzeń),

elementu serwera wersji (szablon dokumentu .docx lub schemat danych .vds) - wybierany we właściwościach bloczka.

W przypadku wybrania pliku schematu danych .vds wymagane jest ponadto wskazanie szablonu dokumentu w postaci binarnej (pole 'template' w rekordzie korzenia).

Szablon w postaci binarnej może zostać wczytany za pomocą:

bloczka Odczyt plików z dysku,
funkcji wyrażeń ReadFile (możliwe wczytanie pliku z dysku lub z serwera wersji za pomocą ścieżki, np vs:///szablon.docx),
pola binarnego z bazy danych.

Dodatkowo, we właściwościach bloczka można zmienić:

format dokumentu wynikowego: PDF lub DOCX,
diagnostyczne logowanie danych przekazywanych z pakietów przetwarzania do komponentu generowania dokumentów.

Po skonfigurowaniu powyższych elementów, w rekordzie korzenia podpowiadany będzie schemat danych wejściowych dokumentu. Wymagane pola muszą zostać zmapowane, aby pakiet mógł być uruchomiony.

Przeciągnij pola ze schematu danych na pola ze struktury danych dokumentu i z menu kontekstowego wybierz Ustaw źródło.

Wygenerowany dokument wynikowy zostanie zapisany w postaci binarnej w rekordzie korzenia w polu document_output/content.

Pole w takiej postaci może zostać w późniejszym etapie zapisane:

na dysk za pomocą funkcji wyrażeń WriteFile. Przykładowa funkcja to:

WriteFile("C:\Raport."+document_output\format,document_output\content)

do bazy danych do pola binarnego. Przeciągnij pole content na pole binarne w strukturze danych i wybierz z menu kontekstowego Ustaw źródło.

Start procesu workflow

Bloczek Start procesu workflow umożliwia uruchomienie wskazanego procesu.

Na panelu Właściwości wskaż proces, który ma zostać uruchomiony.

Przejdź na zakładkę Szczegóły bloczka i wybierz korzeń danych wejściowych, czyli rekord w schemacie danych, dla którego ma zostać uruchomiony proces. Zaznacz rekord i wybierz Wybierz korzeń.
Po wybraniu korzenia zostaną wyświetlone zmienne procesu, które zdefiniowałeś w procesie na zakładce Zmienne.

Wykonaj mapowania id struktury danych procesu, (oraz pozostałe dane jeśli przetwarzanie tego wymaga) z danymi ze schematu danych. Przeciągnij wybrane pola i z menu kontekstowego wybierz opcję Ustaw źródło.

W pakietach przetwarzania można także wywołać proces na operacjach mapowania, korzystając z adnotacji Uruchom workflow.

Na rekordzie lub na polu w schemacie danych kliknij prawym i wybierz z menu kontekstowego opcję Uruchom workflow.

Po zaznaczeniu operacji na karcie Operacje kolejno na na panelu Właściwości możesz wskazać jaki proces ma zostać uruchomiony, lub wybrać proces na schemacie danych.

Możesz także wypełnić pole duszka _Process i w ten sposób wskazać definicję procesu. Wartość wskazana w rekordzie danych jest ważniejsza, niż ew. konfiguracja statyczna. Pozwala to statycznie wskazać proces-szablon służący tylko do podpowiadania parametrów, a faktycznie, w instancjach wywoływać różne procesy.
Po wskazaniu procesu zostaną wyświetlone zmienne procesu, które zdefiniowałeś w procesie na zakładce Zmienne.
Te zmienne zostaną przekazane do procesu.

Po uruchomieniu pakietu przetwarzania możesz podejrzeć czy dane z pakietu zostały przekazane do procesu.

Wybierz z menu głównego Narzędzia opcję Menedżer procesów.
Kliknij dwukrotnie na proces aby przejść do szczegółów przebiegu procesu lub wybierz z menu kontekstowego Śledź wykonanie.

Po kliknięciu w opcję Parametry wejściowe dostępny jest XML z danymi przekazanymi do procesu.

Wywołaj usługę

Bloczek Wywołaj usługę wysyła żądanie do usługi za pomocą WCF i odbiera odpowiedź.

wskazówka

Aby wywołać usługę należy zdefiniować źródło danych patrz: Źródła danych

Wyróżniamy kilka rodzajów usług:

SOAP (wersja 1.1 i 1.2)
POX – Plain Old XML
REST

W przypadku usługi SOAP identyfikacja punktu wejścia odbywa się w oparciu o mechanizm SOAP tzw. Action a treść żądania / odpowiedzi jest kodowana przy pomocy SOAP (jako Body z wyłączeniem pól oznaczonych adnotacją „Nagłówek” typu „Message header”).
W przypadku usługi POX identyfikacja następuje na podstawie nazwy elementu głównego żądania XML, a treść jest kodowana bezpośrednio do/z XML.
W przypadku REST identyfikacja odbywa się na podstawie dopasowania adresu i operacji http (GET, POST, PUT itd..) a treść żądania/odpowiedzi może być kodowana jako XML/JSON/UrlEncode.
W parametrze PathTemplate bloczka określamy wzorzec adresu postaci /Resource/{id}/{subId}, gdzie {id} i {subId} zostaną uzupełnione w adresie fizycznego żądania na podstawie danych z treści żądania, o ile zostały tam oznaczone adnotacją „Nagłówek” typu „PathAndQuery”.
Pozostałe oznaczone tak pola żądania nie występujące w szablonie adresu będą uzupełnione do zapytania http, np. ?q=abc&id=123 zostanie uzupełnione z pól q i id. Pozostałe pola żądania (nie oznaczone taką adnotacją) będą interpretowane jako elementy treści żądania (XML / UrlEncode).

W celu skonfigurowania bloczka, wywołującego usługę WCF systemu zewnętrznego, należy wykonać następujące operacje:

1. Podanie schematu usługi

W przypadku SOAP najlepiej zaimportować pola Action i szablony żądania i odpowiedzi z dokumentu WSDL. W przypadkach pozostałych można się posłużyć bezpośrednio edytorami na zakładkach Request i Response.
W przypadku SOAP w tym celu w szczegółach bloczka, na zakładce Operacja, należy wczytać definicję usługi. Można to zrobić za pomocą:

wskazania pliku z danymi usługi,
wnioskowania schematu usługi na podstawie dostarczonych komunikatów XML,
wskazania adresu sieciowego do pliku WSDL, z którego designer automatycznie pobierze definicję.

Po wczytaniu definicji należy wybrać interesującą nas operację przez zaznaczenie jej na drzewie i naciśnięcie przycisku Wybierz operację, lub przez wybór opcji z menu kontekstowego.

2. Mapowanie parametrów wejściowych

Na zakładce Mapowania należy wybrać miejsce zamocowania usługi do przetwarzanego drzewa danych (za pomocą operacji Wybierz korzeń), a w rezultacie w strukturze pojawią się pola wejściowe usługi, które należy uzupełnić danymi.

Aby dodać rekord/pole, który jest wyszarzony kliknij prawym i z menu kontekstowego wybierz Popraw>Dodaj element.

3. Uzupełnienie konfiguracji środowiska o nowo skonfigurowaną wywoływaną usługę.

Zakładka Konfiguracja zawiera fragment konfiguracji (endpoint) dla wywoływanej usługi, którą należy dodać do plików konfiguracyjnych środowiska uruchomieniowego zgodnie z instrukcją prezentowaną na zakładce.
Ze względu na fakt, że na różnych środowiskach może występować różna konfiguracja usług (różniąca się przykładowo zabezpieczeniem kanału przesyłowego), dlatego konfiguracja WCF dla wywoływanych usług jest realizowana za pomocą standardowych mechanizmów konfiguracyjnych platformy Microsoft.NET.
Na etapie wstępnego projektowania i testowania usług w środowisku projektowym istnieje możliwość skorzystania z kilku prostych, gotowych wiązań WCF (bindings) typu BasicHttpBinding (SOAP 1.1), WsHttpBinding (SOAP 1.2) i WebHttpBinding (POX, REST).
Oprócz typu wiązania podajemy testowy URL usługi, którą chcemy wywoływać (http / https).

Fragment konfiguracji „[name]” należy uzupełnić wybraną przez siebie nazwą, którą podamy również we właściwościach bloczka w zmiennej Nazwa endpointa.

W ramach konfiguracji bloczka możemy określić limit asynchroniczności działania mechanizmu. Wartości większe od zera spowodują, że bloczek w ramach jednego wątku będzie w stanie wysłać i oczekiwać na więcej, niż jedno żądanie na raz. Spowoduje to zwykle przyspieszenie działania całego przetwarzania kosztem zwiększonego wykorzystania zasobów po drugiej stronie komunikacji (zwykle procesora, baz danych itd.).
Ponadto można określić czy bloczek ma odpowiedzi wypuszczać w kolejności ich przychodzenia, czy raczej honorować kolejność żądań.
Należy tu zwrócić uwagę, że systemy z którymi się komunikujemy nie muszą realizować żądań szeregowo i te wysłane wcześniej mogą wrócić później, niż wysłane przed chwilą. W zależności od konfiguracji bloczka może to prowadzić do przestawiania porządku danych wejściowych. Więcej o asynchroniczności można przeczytać w rozdziale Wątki przetwarzania i kolejki rekordów.
Opcja RawResponse powoduje ominięcie w całości parserów zwrotnych. Odpowiedź będzie odczytywana jako pojedyncze pole (binarne lub tekstowe). Szczegóły dotyczące deserializacji odpowiedzi stają się nieistotne — odczytywane jest tylko MESSAGE_BODY, prawdopodobnie bez żadnego opakowania XML dla treści JSON.

Odwzorowanie do XML odbywa się na zasadach opisanych w rozdziale Mapowanie do/z XML i XSD.

Poza tworzeniem treści żądania, bloczek umożliwia także przygotowanie niestandardowych nagłówków SOAP. Dokonujemy tego przy pomocy adnotacji Nagłówek/URI (w treści żądania) na poziomie tuż pod korzeniem żądania. Na elemencie i pod nim zwykle będziemy potrzebować w sposób precyzyjny określić przestrzenie nazw XSD i inne parametry pozwalające przetworzyć nagłówek po stronie odbiorcy.

Przykład integracji z usługą REST

W poniższym przykładzie będziemy pobierać dane o dostępnych typach ofert ubezpieczeniowych z testowej usługi Insurances.

Na początku dodaj nowe źródło danych. Przejdź na panel Źródła danych i wybierz Zarządzaj.

Dodaj nowe środowisko, jako Typ środowiska wybierz Web Service client endpoint (WCF).
Uzupełnij adres usługi oraz metadane.

Stwórz nowy pakiet przetwarzania. Wybierz źródło danych.
Dodaj bloczki Generator danych losowych, Wywołaj usługę oraz Podgląd danych.

Kliknij dwukrotnie w bloczek wywołania usługi i wybierz źródło danych Insurance.

W kolejnym oknie zostanie pobrany adres do usługi.

W poniższym przypadku chcemy tylko pobrać dane ofert. Kliknij dwukrotnie na operację get pod rekordem offers. W tym przypadku nie musimy uzupełniać danych na innych zakładkach.

Zostaniesz przeniesiony na okno Mapowania. Już teraz możesz uruchomić pakiet i przejść na zakładkę Response aby zobaczyć co otrzymujemy z usługi.

W celu zmiany metody przejdź na zakładkę Operacja. Jeżeli nie widzisz dostępnych metod wczytaj ponownie adres usługi wybierając przycisk z paska górnego.

Po uruchomieniu pakietu w bloczku Podgląd danych możesz zobaczyć co zostało zwrócone z usługi.

Autoryzacja

W przypadku gdy usługa wymaga autoryzacji przejdź na zakładkę Request i dodaj pole tekstowe o nazwie Authorization.

Dodaj adnotację do pola Nagłówek/URI (treść żądania).

Z listy wybierz opcję w kolumnie Nagłówek/URI.

Przejdź na zakładkę Mapowania. Dodane pole pojawi się w rekordzie Request. Rekord jest wyszarzony i należy go dodać do schematu danych.
Kliknij na polu i wybierz opcję Popraw>Dodaj element. Jeżeli wybierzesz opcję Dodaj element (stała) do pola zostanie od razu dodana adnotacja, gdzie możesz wprowadzić stałą wartość.

W tym przypadku w polu Źródło wartości możesz wprowadzić token jako stałą.

Jeżeli token jest wprowadzony do kluczy konfiguracyjnych projektu, wówczas znajdziesz go w tabeli CONFIG_KEYS a w wyrażeniach na zakładce ConfigKeys

Żądanie

Bloczek Żądanie tworzy punkt nasłuchu (metodę WebService) i udostępnia jego dane do dalszego przetwarzania.

Konfigurowana w ramach pakietu usługa posiada taką nazwę jak nazwa bloczka typu Żądanie oraz argumenty odpowiadające skonfigurowanej w bloczku strukturze.

ważne

Domyślnie usługi przetwarzają dane w początkowo ustawionym maksymalnie jednym wątku. W razie potrzeby można podnieść liczbę wątków bloczka (zwykle będzie to bloczek Żądanie) do wartości np. 4-10.

Wyróżniamy kilka rodzajów usług:

SOAP (wersja 1.1 i 1.2)
POX – Plain Old XML
REST

W przypadku usługi SOAP identyfikacja punktu wejścia odbywa się w oparciu o mechanizm SOAP tzw. Action. Wartość ta jest domyślnie wyliczana na podstawie nazwy bloczka i przestrzeni nazw kontraktu, ale istnieje możliwość sparametryzowania własnych, dowolnych nazw. Treść żądania / odpowiedzi jest kodowana przy pomocy SOAP (jako Body z wyłączeniem pól oznaczonych adnotacją „Nagłówek” typu „Message header”).
W przypadku usługi POX identyfikacja następuje na podstawie nazwy elementu głównego żądania XML a treść jest kodowana bezpośrednio do/z XML.
W przypadku REST identyfikacja odbywa się na podstawie dopasowania adresu i operacji http (GET, POST, PUT itd..) a treść żądania/odpowiedzi może być kodowana jako XML/JSON/UrlEncode.
W parametrze AddressTemplate bloczka określamy wzorzec adresu postaci /Resource/{id}/{subId}, gdzie {id} i {subId} zostaną dopasowane w adresie fizycznego żądania do dowolnych ciągów znaków alfanumerycznych z wyłączeniem / i pojawią się w treści żądania, o ile zostały tam (w szablonie żądania – w szczegółach bloczka) oznaczone adnotacją „Nagłówek” typu „PathAndQuery”.
Pozostałe pola szablonu żądania nie występujące w szablonie adresu będą wyciągane z treści zapytania http (np. ?q=abc&id=123 zostanie rozparsowane do pól q i id jeśli będą miały stosowną adnotację). Pola żądania REST/POX nie oznaczone taką adnotacją będą interpretowane jako elementy treści żądania (XML / UrlEncode).
Definicja pakietu udostępnianego jako usługa WebService musi rozpoczynać się bloczkiem Żądanie oraz może kończyć się bloczkiem Odpowiedź.
Usługi nie zwracające wyniku nie muszą mieć bloczka Odpowiedź.

W pakietach przetwarzania definiowanych jako usługi WebService zwracające odpowiedzi nie można korzystać z funkcjonalności pakietów:

kolejek,
asynchroniczności

ze względu na to, że nie miałoby to sensu – usługa i tak musi poczekać na wszystkie dane po drodze aby zwrócić klientowi odpowiedź.

W normalnym użytkowaniu bloczki żądania są dopasowywane do publikowanych punktów usługowych WCF na podstawie kontraktów zdefiniowanych w konfiguracji XML programu hosta, która będzie zwykle zawierać dużo dodatkowych elementów dotyczących zabezpieczeń, dodatkowe zachowania itd. Jednak na etapie wstępnego projektowania i testowania usług w środowisku projektowym istnieje możliwość skorzystania z kilku prostych, gotowych wiązań WCF (bindings) typu BasicHttpBinding (SOAP 1.1), WsHttpBinding (SOAP 1.2) i WebHttpBinding (POX, REST).

Odpowiedź

Bloczek Odpowiedź zwraca wynik pakietu – zapytania w ramach usługi WebService.

Konfigurowana w ramach pakietu usługa zwraca w odpowiedzi parametry odpowiadające skonfigurowanej w bloczku strukturze danych
Definicja pakietu udostępnianego jako usługa WebService musi rozpoczynać się bloczkiem Żądanie oraz kończyć się bloczkiem Odpowiedź.

W pakietach przetwarzania definiowanych jako usługi WebService nie można korzystać z funkcjonalności pakietów:

kolejek,
asynchroniczności

ze względu na to, że technologia obsługi usług WCF na platformie Microsoft .NET nie wspiera takiego scenariusza.

Korzystając z bloczków Żądanie i Odpowiedź możesz wystawiać usługi. W celu wywołania usługi zewnętrznej skorzystaj z bloczka Wywołaj usługę.

Przykład budowy usługi REST

W poniższym przykładzie zostanie zbudowana usługa REST pozwalającą na wykonanie kalkulacji kosztów ubezpieczenia. Kalkulacja kosztów ma polegać na przemnożeniu przez wartość stałą pola o nazwie monthCount wysyłanego do usługi.

Stwórz pakiet składający się z bloczków Żądanie, Odwzorowanie w miejscu i Odpowiedź.

Przejdź do właściwości bloczka Żądanie i wybierz Tak w opcji Publish as REST i Nie w opcji Publish as SOAP.

Ustaw wartość PathTemplate na calculate.

Przejdź do szczegółów bloczka Żądanie i dodaj pole liczbowe o nazwie monthCount.

Przejdź do szczegółów bloczka Odzworowanie w miejscu i dodaj pole liczbowe o nazwie Price. Wartość pola wyliczamy wyrażeniem w postaci np.: monthCount*15

Przejdź do szczegółów bloczka Odpowiedź i usuń pole monthCount.

Wróć do głównego obszaru roboczego i uruchom pakiet. Zostanie wyświetlone okno pozwalające otworzyć interfejs www do testowania usługi.

Możesz dodać do pakietu bloczek Podgląd danych aby sprawdzić czy po wykonaniu pakietu zostały zwrócone dane z usługi. W tym przypadku czy zostały wykonane obliczenia dla pola Price.

Zobacz film ilustrujący powyższe zagadnienia i omawiający usługi sieciowe w archITekt.

Usługi sieciowe

Usługa SOAP wywoływana z procesu

Pakiet przetwarzania opublikowany jako usługa SOAP możesz wywołać z procesu za pomocą czynności Usługa sieciowa. Patrz: Komunikacja z pakietem przetwarzania.

Budowa pakietu usługi

Utwórz pakiet z bloczków połączonych w kolejności:
- Żądanie – przyjmuje wywołanie,
- Odwzorowanie w miejscu – przygotowuje dane odpowiedzi,
- Odpowiedź – zwraca wynik,
- opcjonalnie Podgląd danych do testów w archITekt Studio.
W szczegółach bloczka Żądanie zdefiniuj strukturę wejścia, np. pole IdKlienta. Elementowi głównemu (rekordowi głównemu) struktury nadaj własną nazwę, np. Klient, zamiast domyślnej Request. Dzięki temu unikniesz konfliktu nazw z innymi usługami środowiska, patrz: Konflikt nazw elementu głównego.
W szczegółach bloczka Odpowiedź zdefiniuj strukturę wyjścia, np. pola Nazwa, NIP, Adres.
W bloczku Odwzorowanie w miejscu uzupełnij pola odpowiedzi na podstawie pola IdKlienta.
Zaznacz bloczek Żądanie i na panelu Właściwości ustaw:

Właściwość	Przykładowa wartość	Opis
Nazwa bloczka (sekcja Parametry podstawowe)	PobierzDaneKlienta	etykieta bloczka na diagramie
Publikuj jako SOAP (sekcja SOAP)	Tak	operacja jest udostępniana w punkcie końcowym SOAP
Publikuj jako REST / Publikuj jako POX	Nie
Akcja (Action) (sekcja SOAP)	DaneKlienta	nazwa operacji widoczna w WSDL i na liście Metoda w czynności Usługa sieciowa w procesie; jeśli pole jest puste, nazwą operacji jest nazwa bloczka
Nazwa punktu końcowego (Endpoint) (sekcja SOAP)	Klient	opcjonalnie; nazwa kontraktu, do którego trafi operacja
Namespace (sekcja WCF)	`http://example.com/archITekt/Klient`	opcjonalnie; przestrzeń nazw usługi. Do wywołania pakietu z procesu nie jest wymagana, ale pozwala uniknąć konfliktu nazw, patrz: Konflikt nazw elementu głównego

notatka

Jeśli pole Akcja (Action) jest wypełnione, to ono decyduje o nazwie operacji. Na powyższym przykładzie bloczek nazywa się PobierzDaneKlienta, ale w procesie operacja jest widoczna jako DaneKlienta. Jeśli pole Akcja (Action) pozostawisz puste, jako nazwa operacji zostanie użyta nazwa bloczka – w tym przypadku PobierzDaneKlienta.

Żółty trójkąt przy bloczku Żądanie sygnalizuje brak przestrzeni nazw (Namespace) lub nazwy punktu końcowego. Usługa uruchomi się, ale host podstawi wartości domyślne: przestrzeń nazw http://tempuri.org/ i wspólny kontrakt ServiceContractSeed.

Zapisz pakiet i uruchom ponownie usługę Transformation Services środowiska.
Sprawdź, czy usługa jest dostępna: otwórz w przeglądarce adres usługi z dopiskiem ?wsdl, np. http://localhost:44311/<ŚRODOWISKO>-TransformationService?wsdl, i sprawdź, czy widoczna jest operacja DaneKlienta.

Adres usługi zawiera nazwę środowiska (<ŚRODOWISKO>-TransformationService). Kod proxy wygenerowany w procesie dla jednego środowiska nie połączy się z hostem innego środowiska.

Konflikt nazw elementu głównego

Wszystkie usługi SOAP środowiska są uruchamiane w jednym hoście Transformation Services. Dwie operacje SOAP w tym samym hoście nie mogą mieć elementu głównego wejścia o tej samej nazwie w tej samej przestrzeni nazw. Najczęściej dzieje się tak, gdy dwa bloczki Żądanie mają puste pole Namespace: host podstawia obu przestrzeń nazw http://tempuri.org/, a element główny wejścia w obu nazywa się Request.

Objawy

Przy generowaniu kodu proxy w czynności Usługa sieciowa w procesie pojawia się okno Błąd odświeżania proxy z komunikatem „Nie można odświeżyć proxy”. W polach Data wygenerowania proxy i Kod proxy pozostaje wartość <brak_proxy>, a lista Metoda jest pusta.

Po wybraniu Pokaż szczegóły widoczny jest komunikat:

Nie można nawiązać połączenia, ponieważ komputer docelowy aktywnie go odmawia 127.0.0.1:44311

Komunikat ten prawie zawsze oznacza, że host usług nie wystartował. Przyczyny szukaj w logu hosta, a nie w procesie.

Diagnoza

Otwórz log _RUNTIME\LOGS\ERROR.TransformationServicesHost.<MASZYNA>.active.log.
Odszukaj wpis podobny do poniższego:

Root element of an input or output block is not unique among all other hosted services.
Conflicting name: http://tempuri.org/:Request
... block CounterService ... Other service using same name: Usluga.transform, request block PobierzDaneKlienta
Packages successfully started: 1 / 2, failures: 1
Some packages were not started correctly and 'IgnoreInvalidPackages' is set to False

Wpis wskazuje oba pakiety, których bloczki Żądanie mają tę samą nazwę elementu głównego. Jeden z pakietów nie uruchamia się, a ponieważ opcja IgnoreInvalidPackages ma wartość False, host nie otwiera żadnego punktu końcowego. Stąd odmowa połączenia.

Rozwiązanie

Konflikt możesz usunąć na jeden z dwóch sposobów.

Sposób 1 – różne nazwy elementu głównego. W szczegółach bloczka Żądanie zmień nazwę rekordu głównego struktury wejścia tak, aby była unikalna w środowisku. Na poniższym przykładzie usługa CounterService ma rekord główny o domyślnej nazwie Request, a usługa PobierzDaneKlienta – rekord główny Klient. Takie usługi mogą działać w jednym hoście, nawet jeśli pole Namespace pozostaje puste.

Sposób 2 – własna przestrzeń nazw. Nadaj każdej usłudze własną przestrzeń nazw w polu Namespace (sekcja WCF) bloczka Żądanie, np.:

Bloczek Żądanie	Namespace
PobierzDaneKlienta	`http://example.com/archITekt/Klient`
CounterService	`http://example.com/archITekt/Counter`

Opcjonalnie ustaw też Nazwę punktu końcowego (Endpoint), np. Klient i Counter. Wtedy każda usługa ma własny kontrakt zamiast wspólnego ServiceContractSeed.

Inne możliwości:

ustawienie SuffixDuplicateMessageRoots='true' w konfiguracji hosta – host automatycznie dokleja do powtarzających się nazw sufiksy _1, _2 itd. Stosuj tylko w środowiskach nieprodukcyjnych. Patrz: Środowisko uruchomieniowe usług.
ustawienie IgnoreInvalidPackages='true' – host uruchomi się bez błędnych pakietów. To nie rozwiązuje problemu, tylko go ukrywa.

Weryfikacja

Uruchom ponownie usługę Transformation Services.
Sprawdź, czy w logu znajduje się wpis Packages successfully started: 2 / 2 oraz Service host listening at: http://localhost:44311/<ŚRODOWISKO>-TransformationService.
Otwórz w przeglądarce adres usługi z dopiskiem ?wsdl i sprawdź, czy widoczne są obie operacje.
Wygeneruj ponownie kod proxy w czynności Usługa sieciowa w procesie.

wskazówka

Jeśli w środowisku jest kilka usług SOAP, zadbaj, aby ich bloczki Żądanie nie miały elementu głównego wejścia o tej samej nazwie w tej samej przestrzeni nazw. Puste pole Namespace oznacza przestrzeń nazw http://tempuri.org/, więc dwie usługi z elementem głównym Request i pustym Namespace zablokują uruchomienie hosta.
Komunikaty No alive operation found ... transfer/Get w logu są nieszkodliwe. To próby pobrania metadanych przez WS-Transfer, po których designer przechodzi do innej metody.
Ostrzeżenie Endpoint with no dynamic operations ... WebHttpBinding oznacza tylko, że żadna operacja nie jest publikowana jako REST.

Testowanie wywołania usługi sieciowej

Aby sprawdzić, jak wygląda pełna treść zapytania wysyłanego przez bloczek Wywołaj usługę, należy skonfigurować środowisko testowe oraz odpowiednio przygotować elementy pakietu.

1. Konfiguracja Test Uri i parametrów testowych

W elementach konfiguracji bloczka Wywołaj usługę ustaw:

Adres testowy URI – adres, pod który mają być wysyłane testowe zapytania.
Binding testowy – wiązanie wykorzystywane w scenariuszu testowym.
Serializator danych – preferowany sposób serializacji danych (np. JSON, XML).

W bloczku Wywołaj usługę dodaj rekord Request, który będzie zawierał treść wysyłanego zapytania (body).

2. Testowanie pakietu z użyciem PowerShell i ncat

Do monitorowania przesyłanych żądań można wykorzystać:

PowerShell,
narzędzie ncat, pozwalające na uruchomienie lokalnego nasłuchiwania i przechwycenie treści requestu.

Po uruchomieniu pakietu otrzymasz pełną zawartość przesyłanego zapytania, co umożliwia szczegółową analizę i diagnostykę.

Parsowanie JSON

W strukturze danych wykorzystywanej przez pakiet może znajdować się pole typu string zawierające dane w formacie JSON (np. pole jsonObject). Aby je przetworzyć, konieczne jest zmapowanie JSON na strukturę rekordów.

1. Konfiguracja bloczka Odwzorowanie w miejscu

Otwórz bloczek Odwzorowanie w miejscu i przejdź do rekordu zawierającego dane w formacie JSON.
Z menu kontekstowego wybierz: Użyj wartości>Parsowanie XML/JSON.

2. Ustawienia akcji parsowania

Przejdź do właściwości akcji parsowania i skonfiguruj parametry akcji:

ReaderType: Json
Otwórz edytor struktury i odwzoruj format danych zgodnie ze strukturą JSON.

Zasady odwzorowania struktury:

Utwórz rekord wynikowy, w tym przypadku parsedJson jako nazwa rekordu, który będzie reprezentował sparsowane dane.
Dla pól prostych (np. string, number, boolean) dodaj pola o identycznych nazwach, jak w obiekcie JSON.
Dla tablic (arrays):

dodaj multi‑rekord o nazwie zgodnej z nazwą tablicy w JSON,
wewnątrz multi‑rekordu dodaj pole o nazwie _value, określając odpowiedni typ danych.

3. Podgląd danych po parsowaniu

Aby zweryfikować poprawność konfiguracji:

Dodaj bloczek Podgląd danych.
Uruchom pakiet.
W widoku danych zobaczysz strukturę wynikową zawierającą sparsowany JSON.

Zobacz również

Bazy danych

Mechanizm generowania pakietów migracyjnych

Logowanie błędów i ostrzeżeń

Uruchom algorytm​

Utworzenie dokumentu​

Start procesu workflow​

Wywołaj usługę​

Przykład integracji z usługą REST​

Autoryzacja​

Żądanie​

Odpowiedź​

Przykład budowy usługi REST​

Usługa SOAP wywoływana z procesu​

Budowa pakietu usługi​

Konflikt nazw elementu głównego​

Testowanie wywołania usługi sieciowej​

Zobacz również​