Edytor interfejsów

Części interfejsu

Interfejs składa się z co najmniej jednej operacji oraz stylu powiązania.

Operacja jest opisem działania implementowanego przez komponent. Operacja może mieć typ żądanie-odpowiedź, co oznacza że z interfejsu wysyłane jest żądanie i zwracana jest do niego odpowiedź lub typ jednokierunkowy, co oznacza że wysyłane są tylko dane wejściowe i nie ma potrzeby uzyskiwania odpowiedzi. Każda operacja w interfejsie definiuje dane, które można przekazać podczas wywoływania operacji w postaci danych wejściowych do i danych wyjściowych z komponentu. Każda operacja może mieć co najmniej jeden błąd do obsługi warunków błędu. Operacja jednokierunkowa ma tylko dane wejściowe. Styl powiązania określa protokół i format danych dla operacji.

Na poniższym zrzucie ekranu przedstawiono utworzenie interfejsu o nazwie CreditReport (Raport kredytowy). Interfejs CreditReport jest interfejsem do komponentu, który będzie wysyłał bilans konta klienta i uzyskiwał zatwierdzenie transakcji, a także uzyskiwał historię konta klienta i aktualizował jego zdolność kredytową. Wysyłanie bilansu, uzyskiwanie zatwierdzenia i uzyskiwanie historii są operacjami typu żądanie-odpowiedź. Aktualizowanie zdolności kredytowej klienta jest operacją jednokierunkową.

W edytorze interfejsu przedstawione są następujące części interfejsu CreditReport:

• Operacja żądanie-odpowiedź - getBalance. Po jej wywołaniu wysyłany jest bilans konta klienta i uzyskiwane jest zatwierdzenie transakcji. Operacja getBalance zawiera następujące dane wejściowe, dane wyjściowe i błędy:
  • Dane wejściowe - operacja getBalance wysyła zmienną balance (bilans) jako dane wejściowe. Zmienna balance musi mieć typ danych double.
  • Dane wyjściowe - operacja getBalance jako dane wyjściowe zwraca zmienną o nazwie approval (zatwierdzenie). Zmienna approval zawiera łańcuch zalecający zatwierdzenie (jeśli fundusze są odpowiednio wysokie do uzyskania kredytu) lub odrzucenie (jeśli fundusze nie są wystarczające, aby wnioskodawca mógł uzyskać kredyt).
  • Błędy - operacja getBalance może zwrócić jeden z dwóch błędów, które są łańcuchami opisującymi warunek błędu: błąd timeout (przekroczenie limitu czasu) jest zwracany, jeśli usługa czeka zbyt długo na określenie zatwierdzenia, a błąd systemFailure (awaria systemu) jest zwracany, jeśli nie ma możliwości komunikacji lub wystąpiła awaria zasilania.
• Operacja żądanie odpowiedź - getHistory. Po jej wywołaniu wysyłana jest nazwa konta klienta i uzyskiwana jest historia transakcji klienta. Operacja getHistory zawiera następujące dane wejściowe, dane wyjściowe i błędy:
  • Dane wejściowe - operacja getHistory wysyła zmienną customerName (nazwa klienta) jako dane wejściowe. Zmienna customerName musi mieć typ danych string.
  • Dane wyjściowe - operacja getHistory jako dane wyjściowe zwraca zmienną o nazwie customerPastHistory (historia klienta). Zmienna customerPastHistory zawiera łańcuch z rekordem transakcji z przeszłości.
  • Błędy - operacja getHistory może zwrócić jeden z dwóch błędów, które są łańcuchami opisującymi warunek błędu: błąd timeout (przekroczenie limitu czasu) jest zwracany, jeśli usługa czeka zbyt długo na określenie zatwierdzenia, a błąd systemFailure (awaria systemu) jest zwracany, jeśli nie ma możliwości komunikacji lub wystąpiła awaria zasilania.
• Operacja jednokierunkowa - updateCreditRating. Po jej wywołaniu wysyłana jest bieżąca zdolność kredytowa klienta. Operacja updateCreditRating ma następujące dane wejściowe:
  • Dane wejściowe - operacja updateCreditRating wysyła zmienną currentRating (bieżąca zdolność) jako dane wejściowe. Zmienna currentRating musi mieć typ danych string.

Domyślnie wszystkie dodane wejścia i wyjścia dowolnego typu prostego są polami obowiązkowymi. Jeśli interfejs jest używany w czynności personelu i dla tej czynności zostanie wygenerowany interfejs użytkownika klienta, pola wejściowe lub wyjściowe w interfejsie użytkownika klienta zostaną oznaczone gwiazdką, co będzie oznaczało, że są one obowiązkowe i należy określić ich wartości.

Wybór danych wejściowych, danych wyjściowych lub błędów z tabeli spowoduje otworzenie dodatkowych szczegółów w widoku właściwości edytora interfejsów. Na przykład wybranie operacji customerPastHistory spowoduje wyświetlenie poniższych informacji w widoku właściwości. Oprócz wyświetlenia właściwości istnieje również możliwość zmiany nazwy i typu danych. Jeśli operacja customerPastHistory byłaby obiektem biznesowym, możliwe byłoby otworzenie jej w edytorze obiektów biznesowych.

W przypadku kliknięcia poza tabelą zawierającą operacje, dane wejściowe, dane wyjściowe i błędy wyświetlone zostaną właściwości interfejsu, a konkretnie jego nazwa, przestrzeń nazw, folder oraz dokumentacja.

Po wybraniu operacji, a następnie wybraniu karty Szczegóły w widoku właściwości wyświetlany jest styl powiązania oraz typ operacji. Styl powiązania można wyświetlić, ale nie można go edytować. Jeśli interfejs będzie budowany przy użyciu edytora interfejsów, edytor użyje stylu document literal wrapped jako domyślnego stylu powiązania. Więcej informacji na ten temat zawiera sekcja Styl powiązania.

Sposoby rozpoczynania budowy interfejsu

IBM® Integration Designer jest elastycznym środowiskiem programistycznym, które umożliwia określenie najlepszego podejścia do programowania aplikacji. Interfejsy można budować przed implementacją komponentów lub po ich implementacji, a wyniki będą takie same. Proces budowania interfejsów należy dobrać tak, aby uzupełniał konkretny proces programowania.

Jeśli interfejsy mają być najpierw budowane, a później implementowane, należy uruchomić edytor interfejsów z paska menu lub wybierając moduł i wywołując menu kontekstowe. Zostanie wyświetlone menu edytorów i kreatorów perspektywy biznesowej, które zawiera edytor interfejsów.

Innym podejściem jest zbudowanie w pierwszej kolejności komponentu w edytorze składania, a następnie dodanie do niego interfejsu. W tym przypadku po zbudowaniu komponentu należy go wybrać, aby dodać do niego interfejs.

Programowanie interfejsu

Podczas programowania interfejsu można zastosować następujące podejścia. Wybór podejścia zależy od okoliczności. Wszystkie trzy podejścia są przedstawione w dokumentacji.

• Programowanie zstępujące - tej metodologii należy użyć, jeśli brak istniejącego interfejsu, z którym można pracować. Należy uruchomić edytor interfejsów, podać nazwę interfejsu i dodać do niego co najmniej jedną operację. Do każdej operacji dodawane są dane wejściowe, dane wyjściowe i błędy.
• Programowanie wstępujące - tego podejścia należy użyć, jeśli istnieje już interfejs utworzony jako plik WSDL (Web Services Description Language). W tym przypadku jest on importowany do modułu, a następnie uruchamiany jest edytor interfejsów. Edytor wyświetli interfejs jako operacje, dane wejściowe, dane wyjściowe i błędy. Można następnie użyć edytora interfejsów do zmodyfikowania operacji, danych wejściowych, danych wyjściowych i błędów.
• Programowanie zbieżne - tego podejścia należy użyć, jeśli istnieje interfejs który jest w pełni zgodny z potrzebami komponentu w zakresie interfejsu, albo bardzo ich bliski. Należy przeciągnąć interfejs na komponent. Może on pasować idealnie albo może być konieczne wprowadzenie w nim kilku modyfikacji przy użyciu edytora interfejsów, aby mógł działać. Programowanie zbieżne pozwala zaoszczędzić czas.

Restrykcje

Pojedynczy komponent nie może mieć wielu operacji o tej samej nazwie, ponieważ w czasie wykonywania nie można wtedy określić poprawnej operacji. Dlatego też edytor interfejsów nie zezwala na stosowanie więcej niż jednej operacji o tej samej nazwie.

Należy unikać zduplikowanych obiektów biznesowych i zduplikowanych interfejsów WSDL. Użytkownik może nie zauważyć duplikatów, jeśli znajdują się one w innej używanej bibliotece lub w innym używanym module. Patrz temat Duplikaty obiektów biznesowych.