Optima - Normperiode notification (OK21): Difference between revisions
m 1 revision imported |
No edit summary |
||
| Line 69: | Line 69: | ||
eBoks needs to be notified that a new customer is being added. | eBoks needs to be notified that a new customer is being added. | ||
Integration must be enabled in Optima for files to start landing in TO-SD/CUSTOMERNAME_PLANNEDHOURS/incoming. | Integration must be enabled in Optima for files to start landing in TO-SD/CUSTOMERNAME_PLANNEDHOURS/incoming. | ||
'''Remember all the OneNote information!!!''' | '''Remember all the OneNote information!!!''' | ||
'''XML file:''' | |||
# The casing of the <DISPATCH> element in the XML should be <Dispatch> according to the provided structure from Eboks – see below data definition and example from Eboks for reference. Unmarshalling might fail in SD's logic and/or in Eboks logic, when encountering <DISPATCH> .. </DISPATCH> instead of <Dispatch> … </Dispatch> | |||
# We would like to leave out the <DeliveryDate> element in order to trigger sendout of the pdf as soon as Eboks receives it – see below data definition from Eboks for reference. However, as of now, we need clarification from Eboks on whether it should be completely removed (no <DeliveryDate> element at all) or if the value should just be empty (<DeliveryDate></DeliveryDate>) ''''' So please wait with any modifications to <DeliveryDate> for now, we will get back to you''''' | |||
# SSN's (CPR) incorrect, but you noted that already in previous email | |||
EBoks provided structure: | |||
{| class="wikitable" | |||
|'''Name''' | |||
|'''Content''' | |||
|'''Note''' | |||
|- | |||
|MessageID | |||
|Message-ID | |||
|Same as file name | |||
|- | |||
|SenderID | |||
|Sender CVR | |||
|CVR on the sender who made the connection agreement | |||
|- | |||
|SenderName | |||
|Name of sender | |||
|Name of the sender as presented to the receiver | |||
|- | |||
|RecipientID | |||
|Receipient SSN | |||
|The SSN of the receiver | |||
|- | |||
|Title | |||
|Title for the sending | |||
|The title that will be presented to the receiver | |||
|- | |||
|DeliveryDate | |||
|Delivery date if needed | |||
|If not present, the sending will be delivered when received. | |||
|} | |||
Example: | |||
<?xml version="1.0" encoding="UTF-8"?> | |||
<Dispatch> | |||
<MessageID>''MessageID''</MessageID> | |||
<SenderID>11223344</SenderID> | |||
<SenderName>Det gode sygehus</SenderName> | |||
<RecipientID>''1212123456''</RecipientID> | |||
<Title>''MessageTitle''</Title> | |||
<DeliveryDate>2023-11-22</DeliveryDate> | |||
</Dispatch> | |||
'''PDF file:''' | |||
For the PDF file, I believe we need @Trine Hedegaard Sørensen's input. I will follow up with Trine and provide the PDF files to her for inspection. She is currently out of office and back on Dec 15. | |||
Initial thoughts from me, without knowing much about the expected contents of the PDF: | |||
# Content is in English, I believe it was supposed to be Danish. | |||
# The PDF's seems somehow cropped in a way that leaves out information – I might be my viewer that’s the culprit, but I tried opening in Adobe Acrobat, and in Google Chrome with the same results: | |||
Latest revision as of 10:45, 22 October 2025
1. Order FTP and users as in ServiceNow: CS1804280
2. Aktivere Snapshots> Basisoplysninger> Organisation> Indstillinger> Aktiver Øjebliksbillede af plan "Sandt"
3. Deaktivere Feature toggle: Feature_PlannedHoursInHoursPeriodNotifications hvis der er tale om en "Region". Aktivere Feature toggle: FeaturePlannedHoursInHoursPeriodNotifications Hvis der er tale om en "Kommune". Der skal skrives "AKTIVER" i feltet og den vil blive slået til (Laila & Søren kan dette).
4. Check template:
4.1. Navigate to Reference Data>Notifications>Notifications and Templates
4.2. Point and Click on the Planned Hours in Hours Period Notification to open the Notification and Templates Slide In with details of the Planned Hours in Hours Period Notification
4.3. Point and click on Download Template command under the More option. This will download the template. 4.4. Make the changes to the template by translating the text.
4.5. After the file is being translated just save it under the same name and click Change Template button in the Notification slide-in panel
4.6. When prompted upload the translated notification template and save the changes.
4.7. After this each new notification should be sent translated in Danish.
4.8. Please also send us a copy of the translated template so we can get it onto our systems
Create ZD ticket for RLD after this: #914636
Manually trigger reports
To manually trigger the reports for past dates, you can select each unit and use the date one day later than the last date in the Hours Period Configuration, for example - 15.04.2024, which aligns with several previously scheduled background tasks.
For historical reports, please check the execution dates of the task "PlannedHoursInHoursPeriodNotificationsTask" (not "PlannedHoursInHoursPeriodNotificationsBatchTask"), and manually run the notifications for those dates across all units. Also, if you're running historical notifications, I advise that you start running the notifications tasks manually from the past to the future. This approach helps ensure that an employee doesn't receive an outdated notification after a correct one.
OpenShift documentation:
There are a few steps to enabling a new customer:
Order a new "_user" and _"system" ftp account for the new customer please align with the current naming scheme where applicable: PROD_optima_CUSTOMERNAME_plannedhours_user (or TEST_optima_CUSTOMERNAME_plannedhours_user for test environment)\ Add 4 new variables to octopus https://octopus.prod.internal.sd.dk/app#/Spaces-83/projects/ok21-integration/branches/refs%2Fheads%2Fmaster/variables
CustomerFtpConfig[CUSTOMERNAME].enabled -> True CustomerFtpConfig[CUSTOMERNAME].password -> PROD_optima_CUSTOMERNAME_plannedhours_system's password CustomerFtpConfig[CUSTOMERNAME].username -> PROD_optima_CUSTOMERNAME_plannedhours_system CustomerFtpConfig[CUSTOMERNAME].rootfolder -> CUSTOMERNAME_PLANNEDHOURS
Request that sd-sikkerhedsadministration@sd.dk sets the password in CustomerFtpConfig[CUSTOMERNAME].password for prod scope You may enable or disable this integration per customer using the .enabled variable true/false. Provide FTP information to the delivering party (RLDatix) ie.: Username PROD_optima_CUSTOMERNAME_plannedhours_user and password and request that they do a password change on first login. Path to which delivering party should write files ie. TO-SD/CUSTOMERNAME_PLANNEDHOURS/incoming FTP Host, (customer-test-ftp.sd.dk or customer-ftp.sd.dk depending on evnrionment), port: 22 Create release of ok21-integration through octopus, this will make a new Camel route spin up based on the 4 variables. see https://confluence.eg.dk/display/SDI/Octopus+deploy+guides Notice Before eBoks can send out anything to the employee, we need to ensure that they have an agreement with eBoks on sendouts, and that the SenderId of the Dispatch obejct (xml file) matches with an existing agreement for the customer being enabled. eBoks needs to be notified that a new customer is being added. Integration must be enabled in Optima for files to start landing in TO-SD/CUSTOMERNAME_PLANNEDHOURS/incoming.
Remember all the OneNote information!!!
XML file:
- The casing of the <DISPATCH> element in the XML should be <Dispatch> according to the provided structure from Eboks – see below data definition and example from Eboks for reference. Unmarshalling might fail in SD's logic and/or in Eboks logic, when encountering <DISPATCH> .. </DISPATCH> instead of <Dispatch> … </Dispatch>
- We would like to leave out the <DeliveryDate> element in order to trigger sendout of the pdf as soon as Eboks receives it – see below data definition from Eboks for reference. However, as of now, we need clarification from Eboks on whether it should be completely removed (no <DeliveryDate> element at all) or if the value should just be empty (<DeliveryDate></DeliveryDate>) So please wait with any modifications to <DeliveryDate> for now, we will get back to you
- SSN's (CPR) incorrect, but you noted that already in previous email
EBoks provided structure:
| Name | Content | Note |
| MessageID | Message-ID | Same as file name |
| SenderID | Sender CVR | CVR on the sender who made the connection agreement |
| SenderName | Name of sender | Name of the sender as presented to the receiver |
| RecipientID | Receipient SSN | The SSN of the receiver |
| Title | Title for the sending | The title that will be presented to the receiver |
| DeliveryDate | Delivery date if needed | If not present, the sending will be delivered when received. |
Example:
<?xml version="1.0" encoding="UTF-8"?>
<Dispatch>
<MessageID>MessageID</MessageID>
<SenderID>11223344</SenderID>
<SenderName>Det gode sygehus</SenderName>
<RecipientID>1212123456</RecipientID>
<Title>MessageTitle</Title>
<DeliveryDate>2023-11-22</DeliveryDate>
</Dispatch>
PDF file:
For the PDF file, I believe we need @Trine Hedegaard Sørensen's input. I will follow up with Trine and provide the PDF files to her for inspection. She is currently out of office and back on Dec 15.
Initial thoughts from me, without knowing much about the expected contents of the PDF:
- Content is in English, I believe it was supposed to be Danish.
- The PDF's seems somehow cropped in a way that leaves out information – I might be my viewer that’s the culprit, but I tried opening in Adobe Acrobat, and in Google Chrome with the same results: