Page History
...
Alt koden kan findes i følgende Subversion repository:
https://svn.nspop.dk/svn/capgemini/SORServices/NSPcomponents/sorus
Koden kan derefter importeres som projekt i en ønsket IDE (som Eclipse eller IntelliJ), der er ingen eksplicit grund til at skulle bruge en bestemt.
...
| Navn | Beskrivelse | ||
|---|---|---|---|
| SorBackend-stub | Stub version af SOR backend servicen, praktisk at benytte denne under daglig udvikling. Har til opgave at lave en tilfredsstillende substitut for den rigtige backend, komplet med basic authentication og REST services, men som bare accepterer alt input ukritisk. Den har ingen memory overhovedet, ud over at et nyt ID bliver udleveret ved CreateSorEntity operationen (bevares ikke hen over restart af servicen). | SorDB | Indeholder filer med schema til opsætning af CVR whitelisting |
| SorUpdateService | Selve opdatering servicen, inklusiv kode genereret fra WSDL og XSD filer, og unit og integration tests |
...
En war fik kan genereres ved at køre Maven kommandoen:
mvn package
I roden af projektet findes en Projektet er opsat efter guidelines beskrevet for NSP's CI/CD opsætning, som kan findes her NSP Continuous Integration & Delivery. Den docker-compose.yml fil , som laver et deployment af opdater servicen og opsætning, samt database for whitelisting og stub backend service. Dette er den anbefalede måde at prøve en deployment på, da det vil ske i som hører til development er den anbefale måde at lave en deployment af lokalt, da det opsætter et produktion-lignende miljø hver gang. Alle nødvendige databaser samt stub backenden vil blive opsat, og være klar til brug.
Alternativt kan servicen blive deployed på en lokal Wildfly server. Det anbefales at sætte denne op i forhold til hvordan imaget https://registry.nspop.dk/harbor/projects/4/repositories/playground%2Fnsp/tags/stable er defineret (Dockerfile er inkluderet i image). Filen SorUpdateService/target/sor-opdatering.war kopieres til standalone/deployment/ mappen i Wildfly. Ligeledes skal SorUpdateService/resources/sorus-ds.xml (som indeholder opsætning af datasource til whitelisting databasen) kopieres til standalone/deployment/ mappen, imens at SorUpdateService/resources/sorus.properties og SorUpdateService/resources/log4j-sorus.properties skal kopieres til standalone/configuration/ mappen i Wildfly.
...
Hvis der kommer opdatering af XSD filerne for backend servicen, så skal disse lægges ind to steder. Det primære sted der opdateres to steder.
For hvor fra at klasserne for klient implementationen mod backenden, læses WSDL og XSD filer fra externalSorUpdateService/src/main/webapp/schema/sor, da det er hvor at opdater servicen . Det er også herfra at stub backenden genererer sine klasser ud fra. Men hvis stub backend servicen bliver benyttet, så er det vigtigt også at få opdateret external/schema/sor, da det er her at stub servicen genererer sine klasser ud fra., hvis denne benyttes.
For hvor fra at klasserne for server implementationen, læses WSDL filen fra SorUpdateService/src/main/webapp, og alle XSD filer er at finde under SorUpdateService/src/main/webapp/v3/schema.
Backenden genererer en WSDL fil med samtlige typer den benytter indlejret i. For at benytte dem for server implementationen af SORUS skal disse først kopieres ud i separate filer. Yderligere er backenden kun i stand til at sætte typen xs:dateTime på alle dato felter selvom at det bør kun være xs:date. Dette er en begrænsning i .NET som den rigtige backend er skrevet i, men der er ikke oplevet nogen fejl ved manuelt at ændre disse felter til xs:dateÆndringer af backend WSDL fil skal kun ske i external/.