Twoja brama APIM przekazuje żądania do backendu, który sporadycznie zwraca kody 500 lub 504. Musisz ponowić nieudane wywołania do trzech razy z jednusekundowym opóźnieniem, ale tylko dla tych dwóch kodów statusu. Jakiej konfiguracji zasad należy użyć?

Poprawna odpowiedź używa zasady retry (ponawiania) w Azure API Management, która jest przeznaczona do obsługi przejściowych błędów. Atrybuty count="3" i interval="1" określają odpowiednio trzy próby ponowienia i jednusekundowe opóźnienie między nimi. Kluczowy jest atrybut condition, który precyzyjnie definiuje, że ponowienie ma nastąpić tylko wtedy, gdy kod statusu odpowiedzi (context.Response.StatusCode) wynosi 500 lub 504. Wewnątrz zasady retry umieszczono <forward-request /, co oznacza, że to właśnie wywołanie do backendu ma być ponawiane. Pozostałe opcje są nieprawidłowe: Ponawianie bez warunku (<retry count="3" interval="1") spowodowałoby ponawianie wszystkich nieudanych żądań, niezależnie od kodu błędu, co jest niezgodne z wymaganiem. Użycie set-variable i pętli JavaScript w send-request jest zbyt skomplikowane i nieefektywne w porównaniu do wbudowanej zasady retry. Ustawienie limitu czasu w forward-request nie powoduje automatycznego ponawiania żądań przez APIM; jedynie określa, jak długo APIM będzie czekać na odpowiedź z backendu przed zwróceniem błędu limitu czasu.