Know How & Beispiele

Beim Implementieren von repository Jobs hat SAP eine Funktionalität vergessen, nämlich die, einen repo Job auf einen anderen Repository Type zu binden. Das Feld ist in Eclipse einfach ausgegraut, auch wenn man im Bearbeitungsmodus ist.

Wie kann man das nun so lösen, dass man nicht alle Repo Jobs neu anlegen muss, also zum Beispiel wenn man einen neuen Job für ABAP Lastausgleich auch für ABAP Applikationsserver verwenden möchte? Das wäre ja sonst doppelter Aufwand. Außerdem möchte man vielleicht die SAP Repotypen durch eigene ersetzen? Auch dann will man nicht alles nochmal durchlaufen.

Die Antwort liegt wie so oft in der Datenbank. Der Repo Typ wird in der Tabelle mc_jobs über die beiden Spalten mcRepositoryTypeQN und mcRepositoryTypeId ausgesteuert.

Beispiel

update mc_jobs set mcRepositoryTypeQN ='customer.idm.connector.abap:reptype.ABAPLoadBalancedConnection',
mcRepositoryTypeId = 11 where jobid = 1234

Dieses Statement aktualisiert den Repo Typ des Jobs 1234 durch einen anderen Repo Typ.

Wie bekommt man nun die korrekten Werte für die beiden Spalten mcRepositoryTypeQN und mcRepositoryTypeId?

Die einfachste Variante ist das Anlegen eines neuen Rep Jobs für den Ziel-Repotyp und dann

select mcRepositoryTypeQN,mcRepositoryTypeId = 11 from mc_jobs where jobid = 2345

Viel Spass beim IDM programmieren.

Wenn man im SAP Identitiy Management in der Datenbank die Provisionierungs-Queue ansieht, dann kann es sein dass man zB erhält:

select count(*) from mxp_provision

15693

Was macht man nun mit der Zahl? Schwierig, denn absolut kann sie nicht wirklich etwas aussagen. Verschiedene Blogs und Tutorials haben Informationen über die einzelnen Stati, aber ob man sich wirklich drum kümmern muss sieht man nur dann wenn man sich auch ansieht, ob das betrachtete Repo überhaupt online ist. Bei Kunden mit großen Systemlandschaften durchaus ein Thema.

Aus der Verknüpfung mit den States und mit den Repositories die aktiviert sind ergibt sich folgende praktische Abfrage

select state.name, rep.rep_name, prov.* from mxp_provision prov inner join mxp_state state on prov.state = state.statid inner join mc_repository rep on rep.rep_id = prov.repositoryid  where rep.rep_disabled = 0 order by state desc

Die Einträge, die nun noch hochkommen sind die, die man sich wirklich anschauen sollte, sortiert nach dem höchsten Status.

Harte Zeiten mit der Datenbank.

Merken:

https://community.ubnt.com/t5/UniFi-Routing-Switching/Unifi-stopped-due-to-mongodb-error/m-p/2610322#M124215

Die Dokumentation für das Selbsthosting von Jira ist was den Java Keystore betrifft ganz gut.

Für die Vewendung des SSL Zertifikats im server.xml File des Tomcat Servers gibt es aber doch 2 Dinge zu beachten:

Erstens erwartet der Tomcat den JKS im User Home des Jira Users (klingt logisch, man ist aber doch in Versuchung, das keytool unter root laufen zu lassen) und zweitens wäre da noch das Konfigurationsfile, in dem in der Standadauslieferung ein paar Direktiven fehlen.

Bei mir sieht der Jira Connector unter CentOS so aus:

<Connector port="8443" maxHttpHeaderSize="8192" SSLEnabled="true"
relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true" useBodyEncodingForURI="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/home/jira/.keystore" keystorePass="changeit"
ciphers="TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" />