Informacje o przykładzie karty rozliczeniowej
Dotyczy: Pakiet Windows Azure Pack
Przykład karty rozliczeniowej to rozwiązanie programu Microsoft Visual Studio 2012 dostępne w programie https://www.microsoft.com/en-us/download/details.aspx?id=41146. Przykładowa architektura składa się z dwóch części — aparatu podstawowego karty rozliczeniowej i składnika karty rozliczeniowej specyficznego dla systemu. Podstawowy aparat współdziała z interfejsem API rozliczeń pakietu Windows Azure Pack i zapewnia łatwy w użyciu interfejsy. Składnik specyficzny dla systemu składa się z klienta, który komunikuje się z rzeczywistym systemem rozliczeniowym w połączeniu z implementacjami wybranych interfejsów z aparatu podstawowego. Dostępne są dwie karty rozliczeniowe specyficzne dla systemu i klienci — WHMCS i HostBill. W przypadku każdego innego systemu rozliczeniowego należy utworzyć nową implementację.
Aparat podstawowy ma własną bazę danych, aby zachować stan i obsługiwać odzyskiwanie po awarii. Dwa przykłady specyficzne dla systemu dostarczone przez przykład obejmują bazy danych w celu zapewnienia obsługi mapowania tożsamości. Te bazy danych są specyficzne dla implementacji i mogą nie być wymagane podczas tworzenia własnej implementacji karty rozliczeniowej.
Ważne
Podana implementacja specyficzna dla systemu używa bazy danych do wykonywania mapowania tożsamości. Mapuje identyfikatory pakietu Windows Azure Pack na określone identyfikatory systemu rozliczeniowego. Jeśli system rozliczeniowy może używać (lub przechowywać) identyfikatorów pakietu Windows Azure Pack, bazy danych mapowania tożsamości nie są konieczne w ramach implementacji.
Ogólne obserwacje próbek
Karta rozliczeń może być uruchamiana jako usługa systemu Windows lub jako aplikacja konsolowa. Aby uzyskać więcej informacji, zobacz How to Build and Run the Billing Adapter Sample (Jak skompilować i uruchomić przykład karty rozliczeniowej).
Karta rozliczeniowa może być hostowana w dowolnym miejscu, o ile może łączyć się z interfejsami API rozliczeń pakietu Windows Azure Pack i z systemem rozliczeniowym. Jeśli którykolwiek z osób odpowiadających jest używany (interfejs API blokowania lub interfejs API cen), pakiet Windows Azure Pack powinien być również w stanie uzyskać dostęp do karty rozliczeniowej.
Aparat rdzeni karty rozliczeniowej zapewnia silnie typizowane interfejs do obsługi użycia taryfowego. Jednak żaden z systemów rozliczeniowych wdrożonych w tym przykładzie nie zapewnia użycia taryfowego z pudełka bez uzyskiwania dodatkowych dodatków.
Aspekty aparatu podstawowego
Poniżej opisano aspekty aparatu podstawowego. Aby uzyskać informacje o przykładowym projekcie, zobacz About the Billing Adapter Core Engine Sample Files (Informacje o przykładowych plikach aparatu core aparatu karty rozliczeniowej)
Uproszczenie abstrakcji &
Aparat podstawowy stanowi abstrakcję złożoności interfejsu API REST rozliczeń w łatwy w użyciu interfejs, silnie wpisując informacje zebrane za pośrednictwem interfejsu API REST użycia. Aby uzyskać więcej informacji na temat interfejsu API REST użycia użycia, zobacz Dokumentacja interfejsu API REST użycia usługi Azure Pack dla pakietu Windows Azure Pack.
Obsługa błędów
Aparat podstawowy abstrahuje błędy od implementacji specyficznej dla systemu przez wykonanie ponownych prób wewnętrznie. W przypadku błędów pochodzących z pakietu Windows Azure Pack (które są uważane za tymczasowe błędy, takie jak awaria sieci), aparat podstawowy będzie ponawiać próbę do momentu zwrócenia pomyślnej odpowiedzi. W przypadku błędów pochodzących z karty rozliczeniowej (które mogą być tymczasowe lub trwałe), aparat rdzenia ponowi próbę do pięciu razy. Po pięciu razach błąd zostanie uznany za trwały, a aparat rdzenia zatrzyma aparat przetwarzania, czekając na administratora systemu na przeanalizowanie błędu i ręczne rozwiązanie go. Aparat podstawowy zapisuje komunikaty o błędach w dzienniku zdarzeń systemu Microsoft Windows. Aparat usypia się przez wstępnie zdefiniowany czas między próbami ponawiania próby. Aby uzyskać informacje o app.config, zobacz About the Billing Adapter Core Engine Sample Files (Informacje o plikach przykładowych aparatu karty rozliczeniowej).
Uwaga
Aparat może wywołać implementację specyficzną dla systemu do pięciu razy na zdarzenie, dlatego implementacja powinna być idempotentna.
Wybór wzorca/elementu podrzędnego o wysokiej dostępności &
W celu zapewnienia wysokiej dostępności i skalowalności można wdrożyć kartę rozliczeniową na wielu maszynach. Wszystkie osoby reagujące (blokujące interfejs API i interfejs API cen), jeśli są włączone, będą uruchamiane we wszystkich wystąpieniach. Główny & wybór podrzędny zapewni, że tylko jedno wystąpienie każdego procesora (zdarzenia powiadomień i rekordy użycia), jeśli jest włączone, zostanie uruchomione w danym czasie, między procesami i maszynami.
Rejestrowanie
Dzienniki można wyświetlić w usłudze Microsoft Podgląd zdarzeń. Są one dostępne w kanale Microsoft-WindowsAzurePack.BillingAdapter w sekcji Dzienniki aplikacji i usług .
Zarządzanie stanem
Aparat karty rozliczeniowej zachowuje wymagany stan w własnej bazie danych, dzięki czemu może odzyskać odzyskiwanie po awariach. Dzięki temu zdarzenia "zatwierdzone" (które zostały pomyślnie przetworzone przez implementację specyficzną dla systemu) nie będą procesami więcej niż raz.
Aspekty składników specyficznych dla systemu
Przykład obejmuje dwie implementacje specyficzne dla systemu rozliczeniowego (w przypadku systemów rozliczeniowych WHMCS i HostBill). Jeśli masz inny system rozliczeniowy, musisz zapewnić własną implementację interfejsów kart rozliczeniowych. Podczas pisania własnej implementacji należy przestrzegać niektórych wytycznych (zobacz poniżej). Te wytyczne przedstawiono w podanych implementacjach specyficznych dla systemu, dlatego zaleca się użycie jednej z istniejących implementacji jako szablonu i zmodyfikowanie ich zgodnie z potrzebami.
Obsługa ponownych prób
Kod powinien być idempotentny/ponownie uczestniczący. Jeśli podczas przetwarzania żądania wystąpi błąd, aparat karty rozliczeniowej spróbuje ponownie dostarczyć żądanie. Implementacja powinna być w stanie obsługiwać próby ponawiania prób i czyścić\naprawę zdarzeń obsłużonych w połowie. Uwzględnione przykładowe implementacje sprawdzają bieżący stan systemu rozliczeniowego przed próbą wprowadzenia modyfikacji systemu rozliczeniowego. Korzystają również z bazy danych mapowania, aby sprawdzić, czy zdarzenie zostało już pomyślnie przetworzone.
Aspekty przykładu HostBill i WHMCS
Obie przykładowe implementacje współdziałają bezpośrednio z bazą danych systemu rozliczeniowego (ze względu na brak wymaganych wywołań interfejsu API). Wewnętrzna struktura bazy danych systemu rozliczeniowego może ulec zmianie między wersjami, co oznacza, że przykładowe implementacje mogą ulec awarii. Przykładowa implementacja WHMCS została przetestowana w programie WHMCS w wersji 5.2.7, a implementacja biblioteki HostBill została przetestowana na serwerze HostBill w wersji 4.9.8. Jeśli wersja systemu rozliczeniowego jest inna, należy ponownie przetestować bieżące implementacje pod kątem zgodności. Podane implementacje odczytują oczekiwaną wersję z app.config (aby uzyskać więcej informacji na temat app.config, zobacz Informacje o przykładowych plikach aparatu podstawowego karty rozliczeniowej) i nie zostaną uruchomione, jeśli wersja systemu rozliczeniowego nie jest zgodna z oczekiwaną wersją.
Obie implementacje implementują przetwarzanie powiadomień o zdarzeniach i blokujące osoby reagujące na interfejs API. HostBill implementuje również funkcję reagowania na ceny.
Zobacz też
Informacje o przykładowych plikach aparatu podstawowego karty rozliczeniowej
Informacje o przykładowych plikach specyficznych dla systemu kart rozliczeniowych