Page History

...

I praksis vil dette kun være relevant for minlog. STS'ens opgave bliver at leverer en liste af CVR-numre, hentet fra IDSAS, som der skal lave sløring på, såfremt "blurring" er sat til "true". Det vil defor kun være de CVR-numre, som er registreret i IDSAS, som vil blive slørret i praksis.

Eksempel på opsætning af sløring:Eksempel på opsætning af sløring:

INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES ('https://minlog', 'blurring', 'trueV11');

URL til IDSAS sættes i idsas.xml.

...

• Hvis en spæreliste i CRA er for gammel (NextUpdate er overskredet)
• Hvis et certifikat i databasen eller en keystore er udløbet (man skal kunne konfigurere certifikater der ignoreres)
• Hvis et certifikat i databasen eller en keystore er spærret (man skal kunne konfigurere certifikater der ignoreres)
• Hvis XX% antal kald til en eksterne service er fejlet indenfor den sidste YYYY periode (se konfiguration af monitorering)

Der returneres 500 ved alarm, ellers 200.

 Konfiguration af monitorering

Alarm-siden kan konfigureres med hvor mange % kald må fejle til en service, inden for X timer.

Timer (for alle eksterne services) angives i services.xml:

<bean id="serviceInfoCollector" class="dk.sosi.sts.ServiceInfoCollector" scope="prototype">
	<constructor-arg value="24"/> <!-- Hours to record calls to service -->
</bean>

Og % tolerancen af fejl for den enkelte service angives i 'interface.xml'.

Her vises konfigurationen for en enkelt service:

<bean id="monitorPidFailureCheck" class="dk.sosi.sts.monitor.ExternalServiceFailureCheck">
		<constructor-arg ref="pidService"/>
		<constructor-arg value="CPR-PID" />
		<constructor-arg value="5" /> <!-- Max % of calls that can fail before it causes an alarm -->
</bean>

Der findes 3 andre ExternalServiceFailureCheck i interface.xml, som konfigureres på samme måde.

Gammel statusside

STS har en ældre statusside, som kan tilgås ved /sts/checkstatus.

...