API, Manageengine, ServiceDesk, ServiceDesk MSP, ServiceDesk Plus, Windows, , , , , , ,

Odezwał się do nas jeden z czytelników, który zgłosił nam problem z API po aktualizacji do 9222. Rozwiązanie okazuje się banalne…

Po potwierdzeniu przypadłości zabraliśmy się za szukanie przyczyn. Pierwsze podejrzenie padło na aktualizację. Jednak na naszej testowej instalacji SDP (również zaktualizowana do 9222) problem z „krzakami” nie występował.

Konfiguracja czytelnika:

  1. SDP: 9222
  2. DB: MSSQL 2012
  3. OS: Windows Server 2012
  4. Protokół: HTTPS

Postanowiliśmy zrobić szybki test – API + powershell + WebRequest. Ku naszemu zdziwieniu – działa. Więc dlaczego skrypt czytelnika nie działa? Szybki review – mamy to. Jedyną różnicą był użyty przez nas protokół – my użyliśmy https, czytelnik wpisał adres ServiceDesk’u bez protokołu tak więc użyty domyślnie został http. Otwieramy web.xml a tam… domyślna zawartość pliku. Czytelnik używa SDP tylko po https lecz po ostatniej aktualizacji plik web.xml podmienił się na domyślny (podczas aktualizacji) przez co nie działało przekierowanie HTTP do HTTPS (wcześniej taka sytuacja – choć nieprawidłowa – nie powodowała „krzaków”).

A teraz rozwiązanie krok po kroku:

  1. Zatrzymujemy usługę SDP uruchamiając CMD jako administrator
  2. Otwieramy web.xml do edycji
  3. Szukamy </security-constraint>. Powyżej dodajemy: 
          <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
  4. Zapisujemy plik
  5. Startujemy usługę SDP
  6. Weryfikujemy i cieszymy się znów działającym API.

W tym przypadku wszystko zaczęło działać jak należy. Dziękujemy za zgłoszenie błędu i wspólną pracę przy jego rozwiązaniu.

Jeśli to czytasz to zapewne sam doświadczyłeś tego problemu. Mamy nadzieję, że rozwiązanie to zadziałało również u Ciebie.
Zachęcamy wszystkich do kontaktu z nami i informowaniu nas o wykrytych przez Was błędach aplikacji. Postaramy się rozwiązać zgłaszane przez Was problemy oraz pomożemy w kontakcie z oficjalnym supportem ServiceDesk Plus.

 

AKTUALIZACJA 24.08.2016:

Aby nie mieć problemów z „polskimi” znakami używając http należy dokonać zmian w ustawieniach Tomcat’a. Przechodzimy do edycji pliku server.xml w lokalizacji: SDP_HOME \server\default\deploy\jbossweb-tomcat70.sar\ i otwieramy do edycji plik server.xml. Następnie szukamy:


<!-- A HTTP/1.1 Connector on port 8080 -->
<!-- The compression parameters are taken from the default Tomcat server.xml-->
<Connector acceptCount="100" address="${jboss.bind.address}" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript" compression="on" compressionMinSize="2048" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxPostSize="-1" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" noCompressionUserAgents="gozilla, traviata" port="80" redirectPort="8443" server="-"/>

Edytujemy linię dodając:

URIEncoding="UTF-8"

 

Przykładowe ustawienia:


<!-- A HTTP/1.1 Connector on port 8080 -->
<!-- The compression parameters are taken from the default Tomcat server.xml-->
<Connector URIEncoding="UTF-8" acceptCount="100" address="${jboss.bind.address}" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript" compression="on" compressionMinSize="2048" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxPostSize="-1" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" noCompressionUserAgents="gozilla, traviata" port="80" redirectPort="8443" server="-"/>