Zasada MessageLogging

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Co

Jednym z najlepszych sposobów na określenie problemów w środowisku wykonawczym interfejsu API jest rejestrowanie komunikatów. Możesz podłączyć i skonfigurować zasadę MessageLogging w swoim interfejsie API, aby rejestrować niestandardowe komunikaty na dysku lokalnym (tylko Edge dla chmury prywatnej) lub do syslog.

Sample

Syslog

<MessageLogging name="LogToSyslog">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <DateFormat>yyyy-MM-dd'T'HH:mm:ss.SSSZ</DateFormat>
  </Syslog>
  <logLevel>ALERT</logLevel>
</MessageLogging>

Typowym zastosowaniem typu zasady MessageLogging jest logowanie do konta Syslog. Po skonfigurowaniu dla syslog serwer proxy interfejsu API będzie przekazywać komunikaty logu z Apigee Edge do zdalnego serwera Syslog. Musisz już mieć dostępny serwer syslog. Jeśli tak nie jest, dostępne są publiczne usługi zarządzania logami, takie jak Splunk, Sumo Logic i Loggly. Zobacz Konfigurowanie usług zarządzania logami innych firm.

Załóżmy na przykład, że musisz rejestrować informacje o każdej wiadomości żądania, którą interfejs API otrzymuje z aplikacji konsumenckich. Wartość 3f509b58 reprezentuje wartość klucza charakterystyczną dla usługi Loggly. Jeśli masz konto Loggly, zastąp go kluczem loggly. Wygenerowany komunikat logu zawiera 4 wartości: organizację, serwer proxy interfejsu API i nazwę środowiska powiązanego z transakcją oraz wartość parametru zapytania w wiadomości żądania.

Jeśli masz wdrożenie Edge dla Private Cloud, możesz też zapisywać komunikaty logu w pliku.

Syslog przez TLS/SSL

<MessageLogging name="LogToSyslog">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
    <DateFormat>yyMMdd-HH:mm:ss.SSS</DateFormat>
  </Syslog>
  <logLevel>WARN</logLevel>
</MessageLogging>

Możesz wysyłać wiadomości do zewnętrznych dostawców logowania wiadomości przez TLS/SSL, dodając blok <SSLInfo>.

Obrót pliku: rozmiar

<MessageLogging name="LogPolicy">
  <File>
    <Message>This is a test message. Message id : {request.header.messageid}</Message>
      <FileName>test.log</FileName>
      <FileRotationOptions rotateFileOnStartup="true">
        <FileRotationType>SIZE</FileRotationType>
        <MaxFileSizeInMB>10</MaxFileSizeInMB>
        <MaxFilesToRetain>10</MaxFilesToRetain>
      </FileRotationOptions>
  </File>
  <logLevel>ERROR</logLevel>
</MessageLogging>

Rotacja plików zależna od rozmiaru.

Rotacja plików: czas

<MessageLogging name="LogPolicy">
  <File>
    <Message>This is a test message. Message id : {request.header.messageid}</Message>
    <FileName>test.log</FileName>
    <FileRotationOptions rotateFileOnStartup="true">
      <FileRotationType>TIME</FileRotationType>
      <RotationFrequency unit="minute">10</RotationFrequency>
      <MaxFilesToRetain>10</MaxFilesToRetain>
    </FileRotationOptions>
  </File>
  <logLevel>ERROR</logLevel>
</MessageLogging>

Rotacja plików według czasu.

Obrót pliku: czas i rozmiar

<MessageLogging name="LogPolicy">
  <File>
    <Message>This is a test message. Message id : {request.header.messageid}</Message>
    <FileName>test.log</FileName>
    <FileRotationOptions rotateFileOnStartup="true">
      <FileRotationType>TIME_SIZE</FileRotationType>
      <MaxFileSizeInMB>10</MaxFileSizeInMB>
      <MaxFilesToRetain>10</MaxFilesToRetain>
      <RotationFrequency unit="minute">10</RotationFrequency>
    </FileRotationOptions>
  </File>
  <logLevel>ERROR</logLevel>
</MessageLogging>

Rotacja plików zależna od czasu i rozmiaru.

Transmisja włączona

<MessageLogging name="LogPolicy">
  <File>
  ....
  ....
  </File>
  <BufferMessage>true</BufferMessage>
</MessageLogging>

Logowanie wiadomości z włączonym strumieniem


Odwołanie do elementu

Użyj poniższych elementów, aby skonfigurować typ zasady MessageLogging.

Nazwa pola Opis pola

File

Miejsce docelowe pliku lokalnego. (Logowanie plików jest obsługiwane tylko w Edge w przypadku wdrożeń w chmurze Private Cloud). Informacje o tym, gdzie są przechowywane pliki, znajdziesz w sekcji Lokalizacja pliku logu w Edge for Private Cloud.

Message Utwórz komunikat, który ma być wysyłany do pliku dziennika, łącząc tekst ze zmiennymi w celu zebrania potrzebnych informacji. Więcej informacji znajdziesz w sekcji Sample.
FileName Nazwa pliku dziennika, w którym zarejestrowano wiadomość.
FileRotationOptions
rotateFileOnStartup

Atrybut. Prawidłowe wartości: true/false

Jeśli zasada ma wartość Prawda, plik dziennika jest poddawany rotacji przy każdym ponownym uruchomieniu mechanizmu przesyłania wiadomości.

FileRotationType Określa zasadę rotacji (size lub time) pliku dziennika.
MaxFileSizeInMB (W przypadku wybrania size jako typu rotacji) Określa rozmiar pliku logu, który ma wyzwalać przeniesienie komunikatów logu do osobnego pliku przez serwer. Gdy plik logu osiągnie określony rozmiar, serwer zmienia nazwę bieżącego pliku.
RotationFrequency (W przypadku wybrania typu rotacji time) Określa czas w minutach, w którym serwer ma przenieść komunikaty logu do osobnego pliku. Po upływie określonego czasu zmieni się nazwa bieżącego pliku dziennika.
MaxFilesToRetain

Określa maksymalną liczbę plików, które mają być przechowywane w kontekście ustawień rotacji. Wartością domyślną jest 8.

Jeśli podasz 0 (0), pliki dziennika będą przechowywane bez ograniczeń czasowych, ale zgodnie z ustawieniami rotacji plików, ale żaden z nich nie zostanie usunięty ani zmieniony. Dlatego w celu uniknięcia w przyszłości błędów dotyczących całego dysku ustaw tę wartość na wartość większą niż 0 lub zaimplementuj zwykły, automatyczny system trwałego usuwania lub archiwizowania starszych przechowywanych plików logów.

BufferMessage

Jeśli na serwerze proxy jest włączone strumieniowe przesyłanie danych przez HTTP, wiadomości żądań i odpowiedzi nie są buforowane. Jeśli chcesz logować treści, które wymagają przeanalizowania komunikatu procesu, ustaw wartość BufferMessage na wartość true. Przykład znajdziesz na karcie „Obsługiwane przez strumień”. Wartość domyślna: false (fałsz)

Syslog

Miejsce docelowe syslog. Aby dowiedzieć się, jak wysyłać syslog do Splunk, Sumo Logic lub Loggly, zapoznaj się z artykułem Konfigurowanie zewnętrznych usług zarządzania logami.

Message

Utwórz komunikat, który ma być wysyłany do syslog, łącząc tekst ze zmiennymi w celu zebrania potrzebnych informacji. Więcej informacji znajdziesz w sekcji Sample.

Uwaga: po zakończeniu procesu błędów zmienne odpowiedzi nie będą dostępne w PostClientFlow. Używaj zmiennych dotyczących wiadomości do rejestrowania informacji o odpowiedzi na potrzeby sytuacji związanych zarówno z błędem, jak i sukcesem. Zobacz też Uwagi na temat użytkowania.

Host Nazwa hosta lub adres IP serwera, na który powinien być wysyłany syslog. Jeśli nie dodasz tego elementu, wartością domyślną będzie localhost.
Port Port, w którym działa protokół syslog. Jeśli nie dodasz tego elementu, wartość domyślna to 514.
Protocol TCP lub UDP (domyślnie). Protokół UDP jest wydajniejszy, ale protokół TCP gwarantuje dostarczenie logów wiadomości do serwera syslog. W przypadku wysyłania komunikatów syslog przez TLS/SSL obsługiwany jest tylko protokół TCP.
FormatMessage

true lub false (domyślnie)

Opcjonalny, ale do użycia z Loggly wymagana jest właściwość <FormatMessage>true</FormatMessage>.

Ten element pozwala kontrolować format treści generowanych przez Apigee dołączanych do wiadomości. Jeśli zasada ma wartość Prawda, do komunikatu syslog jest dołączany stała liczba znaków, co umożliwia odfiltrowywanie tych informacji z wiadomości. Oto przykład stałego formatu:

<14>1 2023-03-20T09:24:39.039+0000 e49cd3a9-4cf6-48a7-abb9-7ftfe4d97d00 Apigee-Edge - - - Message starts here

Informacje wygenerowane przez Apigee obejmują:

  • <14> – wynik priorytetu (patrz Protokół Syslog) obliczany na podstawie poziomu logu i lokalizacji wiadomości.
  • 1 — bieżąca wersja protokołu syslog.
  • Data z przesunięciem względem czasu UTC (UTC = +0000).
  • UUID procesora wiadomości.
  • „Apigee-Edge – - - ”

Jeśli zasada ma wartość Fałsz (domyślnie), do wiadomości nie będą dodawane te stałe znaki.

PayloadOnly

true lub false (domyślnie)

Ten element ustawia format wiadomości wygenerowanych przez Apigee w taki sposób, aby zawierał tylko treść komunikatu syslog, bez dołączonych znaków określonych przez FormatMessage.

Jeśli nie użyjesz tego elementu lub pozostaw go pusty, domyślną wartością będzie false.

Zobacz FormatMessage.

DateFormat

Opcjonalnie.

Ciąg tekstowy szablonu formatowania używany do formatowania sygnatury czasowej każdego komunikatu logu. Domyślnie Apigee używa yyyy-MM-dd'T'HH:mm:ss.SSSZ. Działanie tego szablonu zostało opisane w dokumentacji klasy SimpleDateFormat w Javie.

SSLInfo

Umożliwia logowanie wiadomości przez SSL/TLS. Używaj z elementem podrzędnym <Enabled>true</Enabled>.

Jeśli nie dodasz tego elementu lub pozostawisz go pusty, wartością domyślną będzie false (brak TLS/SSL).

<SSLInfo>
    <Enabled>true</Enabled>
</SSLInfo>

Tag <SSLInfo> można skonfigurować tak samo jak w punkcie końcowym TargetEndpoint – obejmuje to włączenie dwukierunkowego protokołu TLS/SSL zgodnie z opisem w dokumentacji dotyczącej konfiguracji serwera proxy interfejsu API. Obsługiwany jest tylko protokół TCP.

logLevel

Opcjonalnie.

Prawidłowe wartości: INFO (domyślne), ALERT, WARN, ERROR

Ustaw określony poziom informacji, który ma być uwzględniany w dzienniku wiadomości.

Jeśli używasz elementu FormatMessage (ma wartość Prawda), ustawienie logLevel wpływa na obliczony wynik priorytetu (liczbę w nawiasach kątowych) dołączonych do wiadomości informacji wygenerowanych przez Apigee.

Schematy


Uwagi na temat użytkowania

Jeśli dołączasz zasadę MessageLogging do przepływu serwera proxy interfejsu API, rozważ umieszczenie jej w odpowiedzi ProxyEndpoint w specjalnym procesie o nazwie PostClientFlow. Obiekt PostClientFlow jest uruchamiany po wysłaniu odpowiedzi do klienta wysyłającego żądanie, co zapewnia, że wszystkie wskaźniki są dostępne do logowania. Szczegółowe informacje o korzystaniu z PostClientFlow znajdziesz w dokumentacji konfiguracji serwera proxy interfejsu API.

Proces PostClientFlow wyróżnia się pod 2 względami:

  1. Jest wykonywana tylko w ramach procesu odpowiedzi.
  2. Jest to jedyny przepływ wykonywany po wystąpieniu błędu przez serwer proxy.

Ponieważ jest wykonywane niezależnie od tego, czy użycie serwera proxy powiodło się, czy nie, możesz umieścić zasady MessageLogging w PostClientFlow, aby mieć pewność, że będą zawsze wykonywane.

Ten obraz śledzenia pokazuje zasadę MessageLogging wykonywaną w ramach PostClientFlow po wykonaniu zasadyDefaultFaultRule:

W tym przykładzie błąd z powodu nieprawidłowego klucza spowodowała zasada Weryfikacja klucza interfejsu API.

Poniżej znajduje się definicja punktu ProxyEndpoint, która zawiera obiekt PostClientFlow:

<ProxyEndpoint name="default">
  ...
  <PostClientFlow>
    <Response>
      <Step>
        <Name>Message-Logging-1</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

Edge loguje komunikaty w formie zwykłego tekstu, a możesz skonfigurować logowanie tak, aby uwzględniało zmienne, takie jak data i godzina odebrania żądania lub odpowiedzi, tożsamość użytkownika żądania, źródłowy adres IP, z którego wysłano żądanie itd. Komunikat logu Edge asynchronicznie, co oznacza, że do interfejsu API nie są wprowadzane żadne opóźnienia, które mogą być spowodowane blokowaniem wywołań.

Zasada MessageLogging zapisuje zarejestrowane wiadomości w pamięci w buforze. Rejestrator wiadomości odczytuje wiadomości z bufora, a następnie zapisuje wiadomości w skonfigurowanym przez Ciebie miejscu docelowym. Każde miejsce docelowe ma własny bufor.

Jeśli szybkość zapisu w buforze wzrośnie powyżej wartości odczytu, bufor przepełni się, a logowanie się nie powiedzie. W takim przypadku w pliku dziennika możesz znaleźć komunikat zawierający te informacje:

Log message size exceeded. Increase the max message size setting

Jeśli ten problem wystąpi w Edge dla Private Cloud w wersji 4.15.07 lub starszej, znajdź plik message-logging.properties i użyj tego rozwiązania:

Zwiększ właściwość max.log.message.size.in.kb (wartość domyślna = 128 KB) w pliku message-logging.properties.

W przypadku Edge for Private Cloud w wersji 4.16.01 lub nowszej ustaw właściwość conf_message-logging_max.log.message.size.in.kb w pliku /opt/apigee/customer/application/message-processor.properties i ponownie uruchom procesor wiadomości.

Uwaga: zmienne wiadomości z odpowiedzią w Edge nie są dostępne w przepływie błędów. Te zmienne są również niedostępne w PostClientFlow, jeśli poprzedni proces był przepływem błędów. Jeśli chcesz rejestrować informacje o odpowiedzi z PostClientFlow, użyj obiektu message. Możesz użyć tego obiektu, aby uzyskać nagłówki i inne informacje z odpowiedzi niezależnie od tego, czy wystąpił błąd. Więcej informacji i przykład znajdziesz w artykule Zmienne wiadomości.

Kontrolowanie sygnatury czasowej komunikatu logu w Edge dla Private Cloud

Domyślnie sygnatura czasowa we wszystkich komunikatach logu ma format:

yyyy-MM-dd'T'HH:mm:ss.SSSZ

To domyślne ustawienie systemowe może zostać zastąpione w przypadku miejsc docelowych logu Syslog za pomocą elementu DateFormat. Działanie tego szablonu zostało opisane w dokumentacji klasy SimpleDateFormat w Javie. Zgodnie z tą definicją pole yyyy zostanie zastąpione 4-cyfrowym rokiem, MM – 2-cyfrowym numerem miesiąca itd. Powyższy format może skutkować ciągiem takim:

2022-09-28T22:38:11.721+0000

Do sterowania tym formatem możesz używać właściwości conf_system_apigee.syslogger.dateFormat w procesorze wiadomości Edge. Na przykład zmień format wiadomości na:

yy/MM/dd'T'HH:mm:ss.SSSZ

..Zastępowanie łączników ukośnikami i skracanie do dwucyfrowego roku powoduje zapisanie sygnatury czasowej w formacie:

22/09/28T22:38:11.721+0000

Aby zmienić format:

  1. Otwórz plik message-processor.properties w edytorze. Jeśli plik nie istnieje, utwórz go:
    > vi /opt/apigee/customer/application/message-processor.properties
  2. Ustaw odpowiednie właściwości:
    conf_system_apigee.syslogger.dateFormat=yy/MM/dd'T'HH:mm:ss.SSSZ
  3. Zapisz zmiany.
  4. Sprawdź, czy plik właściwości należy do użytkownika „apigee”:
    > chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  5. Ponownie uruchom procesor wiadomości Edge:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart

Lokalizacja pliku logu w Edge for Private Cloud

Edge dla Private Cloud w wersji 4.16.01 i nowszych

Domyślnie logi wiadomości Private Cloud znajdują się w tym katalogu w węzłach procesora wiadomości:

/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/

Domyślną lokalizację logu możesz zmienić, modyfikując właściwości w pliku message-logging.properties w procesorach wiadomości:

  • bin_setenv_data_dir – ustawia ścieżkę główną przechowywania plików dziennika. Przykład: bin_setenv_data_dir=/opt/apigee/var/log
  • conf_message-logging_log.root.dir – jeśli ustawisz ścieżkę względną, np. conf/message-logging.properties+log.root.dir=custom/folder/, the path is appended to the bin_setenv_data_dir location.,

    Jeśli ustawisz ścieżkę bezwzględną, na przykład conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages, logi wiadomości będą przechowywane w /opt/apigee/var/log/messages/messagelog/. Ścieżka bezwzględna ma pierwszeństwo przed wartością bin_setenv_data_dir.

    Pamiętaj, że musisz odwoływać się do właściwości jako conf/message-logging.properties+log.root.dir, ponieważ domyślnie jest ona komentowana. Więcej informacji znajdziesz w artykule o ustawianiu tokena, który jest obecnie komentowany.

Jeśli chcesz przechowywać pliki logów w płaskiej strukturze plików, aby wszystkie pliki dziennika były umieszczane w tym samym katalogu, ustaw parametr conf/message-logging.properties+enable.flat.directory.structure na wartość true w pliku message-logging.properties. Wiadomości są przechowywane w katalogu określonym przez powyższe właściwości, a nazwy plików mają postać {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}.

Aby ustawić te właściwości:

  1. Otwórz plik message-processor.properties w edytorze. Jeśli plik nie istnieje, utwórz go:
    > vi /opt/apigee/customer/application/message-processor.properties
  2. Ustaw odpowiednie właściwości:
    conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages
  3. Zapisz zmiany.
  4. Sprawdź, czy plik właściwości należy do użytkownika „apigee”:
    > chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  5. Ponownie uruchom komponent Edge:
    > /opt/apigee/apigee-service/bin/apigee-serviceedge-message-processor restart

Edge dla Private Cloud w wersji 4.15.07 i starszych

Domyślnie logi wiadomości w procesorach wiadomości znajdują się w tym miejscu:

/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/

Domyślną lokalizację logu możesz zmienić, modyfikując te właściwości w pliku message-logging.properties w procesorach wiadomości:

  • data.dir – ustawia ścieżkę główną miejsca na pliki dziennika. Na przykład data.dir=/opt/apigee4/var/log
  • log.root.dir – jeśli ustawisz ścieżkę względną, np. log.root.dir=custom/folder/, do lokalizacji data.dir zostanie dodana ścieżka.

Na przykład połączenie tych 2 właściwości spowoduje ustawienie katalogu logowania na /opt/apigee4/var/log/custom/folder/messagelog/ (uwaga: /messagelog jest dodawany automatycznie).

Jeśli ustawisz w tym polu ścieżkę bezwzględną, np. log.root.dir=/opt/apigee4/var/log/messages, dzienniki wiadomości będą przechowywane w lokalizacji /opt/apigee4/var/log/messages/messagelog/. Ścieżka bezwzględna w pliku log.root.dir ma pierwszeństwo przed plikiem data.dir.

Jeśli chcesz przechowywać pliki logów w płaskiej strukturze, aby wszystkie pliki dziennika były umieszczane w tym samym katalogu, ustaw właściwościenable.flat.directory.structure na wartość true w pliku message-logging.properties w procesorach wiadomości. Wiadomości są przechowywane w katalogu określonym przez powyższe właściwości, a nazwy plików mają postać {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}.

Domyślne wartości zmiennych w szablonie wiadomości

Wartości domyślne dla każdej zmiennej w szablonie wiadomości możesz określić oddzielnie. Jeśli np. nie można znaleźć zmiennej request.header.id, jej wartość jest zastępowana wartością unknown.

<Message>This is a test message. id = {request.header.id:unknown}</Message>

Wspólną wartość domyślną można określić dla wszystkich nierozstrzygniętych zmiennych, ustawiając atrybut defaultVariableValue w elemencie Message:

<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>

Konfigurowanie usług zarządzania dziennikami innych firm

Zasada MessageLogging umożliwia wysyłanie komunikatów syslog do zewnętrznych usług zarządzania logami, takich jak Splunk, Sumo Logic i Loggly. Jeśli chcesz wysyłać protokół syslog do jednej z tych usług, zapoznaj się z dokumentacją tej usługi, aby skonfigurować hosta, port i protokół usługi, a następnie odpowiednio ustaw element Syslog dla tej zasady.

Konfiguracja zarządzania dziennikami innych firm znajdziesz w tej dokumentacji:

Informacje o błędach

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wywołuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku błędów.

Błędy w czasie wykonywania

Te błędy mogą wystąpić podczas wykonywania zasady.

Kod błędu Stan HTTP Przyczyna
steps.messagelogging.StepDefinitionExecutionFailed 500 Zobacz ciąg błędu.

Błędy wdrażania

Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego te zasady.

Nazwa błędu Przyczyna Napraw
InvalidProtocol Wdrożenie zasady MessageLogging może się nie udać z powodu tego błędu, jeśli protokół określony w elemencie <Protocol> jest nieprawidłowy. Prawidłowe protokoły to TCP i UDP. W przypadku wysyłania komunikatów syslog przez TLS/SSL obsługiwany jest tylko protokół TCP.
InvalidPort Wdrożenie zasady MessageLogging może się nie powieść z tym błędem, jeśli numer portu nie jest określony w elemencie <Port> lub jest nieprawidłowy. Numer portu musi być liczbą całkowitą większą od 0.

Zmienne błędów

Te zmienne są ustawiane, gdy wystąpi błąd środowiska wykonawczego. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z naruszeniem zasad.

Zmienne Gdzie Przykład
fault.name="fault_name" fault_name to nazwa błędu podana w tabeli Błędy środowiska wykonawczego powyżej. Nazwa błędu to ostatnia część kodu. fault.name Matches "StepDefinitionExecutionFailed"
messagelogging.policy_name.failed policy_name to określona przez użytkownika nazwa zasady, która spowodowała błąd. messagelogging.ML-LogMessages.failed = true

Przykładowa odpowiedź na błąd

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.messagelogging.StepDefinitionExecutionFailed"
      },
      "faultstring":"Execution failed"
   }
}

Przykładowa reguła błędu

<FaultRule name="MessageLogging">
    <Step>
        <Name>ML-LogMessages</Name>
        <Condition>(fault.name Matches "StepDefinitionExecutionFailed") </Condition>
    </Step>
    <Condition>(messagelogging.ML-LogMessages.failed = true) </Condition>
</FaultRule>


Zmienne przepływu

W przypadku błędu zgodności z zasadami te zmienne są wypełniane.

  • messagelogging.failed
  • messagelogging.{stepdefinition-name}.failed

Powiązane artykuły