...
Som arbejdsgiver ønsker jeg at anvende CV-service med ESCO-STAR koder ved “Jeg søger som”
Acceptkriterier:
CV indlæses med JobSearch-CVService version 2
“Jeg søger som” præsenteres med udgangspunkt i ESCO-STAR koder fra felterne:
jobTargetInfo.jobTargets.JobTargetDto[*].conceptUriDa
jobTargetInfo.jobTargets.JobTargetDto[*].aliasIdentifier
Note: Er i dag jobTargetInfo.jobTargets.JobTargetDto[*].discoWebIdentifier
conceptUriDa og aliasIdentifier oversættes til tekst uanset EscoStarStatus og validFrom / validTo
Jeg søger som præsenteres i format: <stillingsbetegnelse> [“(“<alias>”)”]. Eksempler (fiktive):
“fysiker”
“fysiker (kernefysiker)”
Wireframe (eksisterende, uændret efter denne US):
Stillingsbetegnelser fra Taxonomy silo er cachede (evt. kun relevante attributter)
Kilde GET /v1/EscoStar/occupations jf. /wiki/spaces/GI/pages/2352480306
Note: STARs arkitekter har besluttet, at applikationer ikke må lave direkte opslag. Det er OK at refreshe cache én gang i døgnet (man kan også abonnere på ændringer i eventbroker, men det forekommer for kompliceret). Jobnet har en cache, som evt. kan anvendes. Samme cache anvendes i andre typeaheadfelter i JobAG og skal ikke genimplementeres i hver user story.
Noter fra UAM:
a. FB 216995 pkt. 1 og 2 bør være løst med denne user story.
b. Det skal testes, at filtre for uddannelse og erfaring fungerer. Skal give færre hits
c. Søgeprofiler skal testes, herunder at man kan åbne opdaterede CV’er (med flag-markering) uden at få fejl
d. Regressionstest af VIR-1289 bør udføres, når denne user story er klar
VIR-2184 JobAG anvender ESCO-STAR koder til type-ahead ved CV-søgning
...
Type-ahead i “Søg” anvender ESCO-STAR stillingsbetegnelser fra Taxonomy silo ifm,. “Søger job som”
Kun aktive stillingsbetegnelser (EscoStarStatus = 1)
Liste hentes med: GET /v1/EscoStar/occupations
Inkl. aktive alias (EscoStarStatus = 1) - vises som “<stillingsbetegnelse> (<alias>)- valg oversættes til stillingsbetegnelse
Type-ahead omfatter fortsat og uændret også kvalitikationer
Type-ahead felt “Søg”:
Stillingsbetegnelser fra Taxonomy silo er cachede (evt. kun relevante attributter)
Kilde GET /v1/EscoStar/occupations jf. Taxonomy.EscoStarService (2021-1) /wiki/spaces/GI/pages/2352480306
Note: STARs arkitekter har besluttet, at applikationer ikke må lave direkte opslag. Det er OK at refreshe cache én gang i døgnet (man kan også abonnere på ændringer i eventbroker, men det forekommer for kompliceret). Jobnet har en cache, som evt. kan anvendes. Samme cache anvendes i andre typeaheadfelter i JobAG og skal ikke genimplementeres i hver user story.
...
Som EU ønsker jeg at modtage jobønsker som ESCO-koder
Acceptkriterier:
CV indlæses med JobSearch-CVService version 2
jobTargets/JobTargetDto/conceptUriDa
Note: Uændret struktur, men conceptUriDa erstatter discoWebIdentifier
EURES sender ESCO-koder til EU ved jobønsker
Danske ESCO-STAR tilføjelser oversættes til nærmeste parent, som findes i ESCO XML element for jobønsker: <CandidatePositionPreferences>/<JobCategory>/<JobCategoryCode>
Kilde: jobTargets/JobTargetDto/conceptUriDa
Note: Uændret struktur, men conceptUriDa erstatter discoWebIdentifier
EURES sender ESCO-STAR preferredLabelDa som Decription til EU ved jobønsker
XML element for Description til jobønsker: <CandidatePositionPreferences>/<JobCategory>/<ns2:Description>
Kilde: OccupationDto/preferredLabelDa fra /wiki/spaces/GI/pages/2352480306 identificeret af jobTargets/JobTargetDto/conceptUriDa
Note: Uændret struktur. preferredLabelDa tages direkte fra ESCO-STAR, dvs. danske tilføjelser skal ikke mappes til ESCO (i modsætning til ESCO koder, hvor danske tilføjelser mappes jf. acceptkriterier)
EURES sender ESCO-koder til EU ved arbejdserfaring
XML element for arbejdserfaring: <EmploymentHistory>/<EmployerHistory>/<PositionHistory>/<JobCategoryCode>
Kilde: previousJobExperiences/PreviousJobExperienceDto/conceptUriDa
Note: Uændret struktur, men conceptUriDa erstatter discoWebIdentifier
ESCO koder (conceptUriEu) på CV videregives til EURES
CVService returnerer conceptUriDa, som oversættes til conceptUriEu via cachet TaxonomyService
Note: Cache betyder måske blot, at klassifikation indlæses ved start af batchjob
Indsættes i element <JobCategoryCode> (under <CandidatePositionPreferences>/<JobCategory>)
Note: Erstatter ISCO koder i samme elementer under <CandidatePositionPreferences>/<JobCategory> hhv. <PositionHistory>/<JobCategoryCode>
Danske tilføjelser (conceptUriEu = null) oversættes til nærmeste ovenliggende ESCO kode ved at følge parentConceptUriDa op i hierarkiet indtil conceptUriEu er defineret.
Note: Der anvendes samme mapning fra ESCO-STAR til ESCO på alle ISCO/ESCO-relaterede felter på såvel jobannoncer som CV’er. De øvrige ISCO/ESCO-relaterede felter adresseres i andre user stories i andre epics. Vi bør derfor implementere en fælles mekanisme.
Statiske attributter til EURES i XML i elementer <JobCategoryCode> er:
<JobCategoryCode listName="ESCO_Occupations" listVersionID="ESCOv1" listURI="https://ec.europa.eu/esco/portal" listSchemeURI="https://ec.europa.eu/esco/portal">Note: Var tidligere:
<JobCategoryCode listName="ISCO2008" listURI="http://ec.europa.eu/esco/ConceptScheme/ISCO2008" listVersionID="2008">
Mapningsspecifikationen er opdateret
Note: XML med jobannoncer kan fortsat valideres og replikeres med EU’s EURES NCO debug tool: /wiki/spaces/CITY/pages/227541394 .
Note: Eksempel:
<JobCategoryCode listName="ESCO_Occupations" listVersionID="ESCOv1" listURI="https://ec.europa.eu/esco/portal" listSchemeURI="https://ec.europa.eu/esco/portal">http://data.europa.eu/esco/occupation/01484951-15e6-4b88-a20f-1201868d36a0</JobCategoryCode>Alle CV’er skal regenereres for at bruge nye koder ved idriftsættelse af 2021-2
Bestilles hos SF med FB-sag. Kørslen med regenerering skal være afsluttet inden det normale EURES CV batchjob igen må afvikles.
EU skal orienteres om at alle CV’er udskiftes ifm. overgang fra ISCO til ESCO så EU er klar over at det ikke er en fejlsituation. Det kan SF eller Bjarne gøre.