DIGITAL - GENESIS Accessing Genesis Data via API

DIGITAL - GENESIS Accessing Genesis Data via API

Notes
Podsumowanie: Artykuł opisuje, jak odczytywać dane z systemu Genesis za pomocą API. Przykłady zostały wykonane w środowisku testowym Postman. Proces konfiguracji obejmuje zarówno ustawienia systemu Genesis, jak i konfigurację certyfikatów serwera.

 IIS SSL Certificate 


Certyfikat w IIS do API służy do zapewnienia szyfrowanej komunikacji HTTPS i uwierzytelnienia serwera, aby klienci (Postman, przeglądarka, aplikacje) mogli bezpiecznie wymieniać dane z API

Przygotowanie Certyfikatu

 Microsoft Management Console 


Dodaj/Usuń przystawkę


Dodać -  Certyfikaty - Konto komputera


Certyfikat musi:

posiadać klucz prywatny (Private Key) 
być ważny (not expired) 
mieć CN / SAN zgodny z hostname
mieć poprawnego Issuer (wydawcę)

Warning
Bez klucza prywatnego IIS nie może używać certyfikatu.





HTTPS Binding w IIS

Port: 443 (lub inny jeśli skonfigurowany)
Certificate: poprawny certyfikat



Ustawienia certyfikatów serwera:


Certyfikat musi być na liście certyfikatów dostępnych dla usług IIS


Uprawnienia do korzystania z certyfikatu


Użytkownicy

IIS używa konta aplikacji (Application Pool Identity) do obsługi HTTPS.
Jeśli private key nie jest dostępny dla tego konta IS nie odpali HTTPS, pojawią się błędy typu Bad Gateway 502


GENESIS

Ustawienia w Workbench

FrameWorX Server location

Address - użyć adresu serwera (nie localhost/IP address)


Security 

Security w trybie Testing lub Active
Musi istnieć min 1 User

Global Settings - Web login

Aktywować funkcję lgowania web (Enable)
Użyć wcześniej skonfigurowanego certyfikatu 




Utworzenie nowego OIDC Relying Parties

Relying Party -  aplikacja „zaufana” przez serwer OIDC (w tym przypadku Postman REST Client).
Relying Party musi znać:
Client ID
Client Secret
Redirect URL (gdzie OIDC wysyła kody)


Nadać nazwę i utworzyć Secret
Przykład: Name: Postman, Secret: sec
Zaznaczyć Allow refresh tokens 
Ustawić redirect URL:  to „adres, do którego OIDC oddaje token lub kod autoryzacyjny po loginie
Redirect URL zdefiniowany w Relying Parties musi być taki sam, jak w kliencie (Postman)
W testach z Postmanem użyto http://localhost, bo Postman potrafi nasłuchiwać redirecty lokalnie
W praktyce redirect URL to zwykle adres publiczny aplikacji np. https://myapp.domain.com/oauth/callback




Usługi

Uruchomienie usług Web API i Web Services


Ustawienia aplikacja Postman:


Link do pobrania aplikacji:
https://www.postman.com/product/rest-client/

Konfiguracja funkcji GET


(w przykładzie odczyt BI Model)




Authorization:
Dowolny Token Name 
Grand Type: Authorization code 
Callback URL - taki sam jak Redirect URL w konfiguracji Relying Parties
Auth URL: https://hostname/fwxserverweb/security/connect/authorize
Access token URL: https://hostname/fwxserverweb/security/connect/token
Client ID: taki sam jak "Name" w konfiguracji Relying Parties
Client Secret: aki sam jak Secret w konfiguracji Relying Parties
Scope (np. fwxserver offline_access)
fwxserver - token pozwala klientowi pobierać dane z FWX REST API.
offline_access - pozwala na uzyskanie refresh token, czyli możliwość odświeżenia access tokena bez ponownego logowania użytkownika
Client Authentication: Send Basic Auth Header



Wybierz Get New Access Token i wpisz poświadczenia (użytkownik z Workbench - Security)



Po walidacji:


Use Token


Wysłanie komendy GET:


Wynik w JSON:




Konfiguracja POST

Przykład na wpisywanie do assetu (POST)
Body Raw typu JSON

[

{ "PointName": "ac:StaticValue", "Value": 66 },

{ "PointName": "svrsim:out double", "Value": 42.0 }

]