Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Page content

Background

This page outlines the process to generate a Full Notification File (DNF) for a Deanery/Local Office. This is a manual process and is normally required on Day 1 of a new Local Office switching on the TIS-ESR interface where they've previously been using the Intrepid-ESR interface. It may also be requested where ESR has made some changes to their MEDROT (Medical Rotations) implementation. Another instance where this may be required, is where there has been a possible period of outage in the interface and as a result the placements information on ESR may need to be refreshed. 

The DNF file provides a snapshot of current and next incumbent for all positions received from ESR per Local Office.


Process to request a Full Notification File to be sent

It may be required to generate a DNF file subsequent to Day, but this will have to be made by request from ESR. The circumstance under which one may be required, is where there might have been a possible outage of the interface for a period of time and therefore ESR being made out of sync on placement details as a result.

The Full Notification File, if requested with sufficient prior notice by ESR (to allow for the task to be sprint planned and prioritised), can be manually generated for a Local Office and sent as per the schedules. Any request from ESR to generate a DNF file should be sprint planned and priority assessed by Product Owners relatively to other TIS priorities. The request should also contain which Local Office/s require a DNF to be generated.


How to run ESR Full Notification?

Full ESR notification file can be generated per deanery at a time.

Follow the below steps in the same order:

  1. Take a backup of table EsrNotification in tcs database.
  2. Take a backup of table EsrNotificationDetailsRecord in ESR database.
  3. The full notification should be triggered after the daily applicant and notification jobs are finished or during the weekends when there are not expected to be activities on TIS. The last one starts at 5.30 p.m. Ideally this should be carried out over the weekend as there is not much of user interactions with the TIS application. 
    1. The implication of running full notification results in duplicate high volume of applicant records generated during applicant export. 
  4. Run the job https://build.tis.nhs.uk/jenkins/job/tis-esr-etl-full-notification/ with the below options selected: 
    1. PLATFORM: prod
    2. whichever environment you want the full load to run
    3. OFFICE: Select the name of the  deanery code you want to run the full load against.
    4.  
    5. ESR_APP_LOG_LEVEL: Change it to DEBUG if you want to monitor the logs. Otherwise leave it as INFO.
  5. The Jenkins job finishes after triggering the esr-etl load. ssh to the environment and grep the esr-etl log to see the progress of the load.

    heetis@HEE-TIS-VM-STAGE-APPS-GREEN:~$ docker ps -a|grep esr-etl
    83729acdb151        repository.tis.nhs.uk:5000/hee/esr-etl:1.0.22.Final                             "java -XX:+UnlockE..."   7 minutes ago       Exited (0) 6 minutes ago                                                      esretl_esr-etl_1
    heetis@HEE-TIS-VM-STAGE-APPS-GREEN:~$ docker logs esretl_esr-etl_1
  6. Once the job finishes you should see a DNF file generated and uploaded to the corresponding Azure account inside the <currentDate>-outbound folder.
  7. The DNF file is picked up by the next FTP synch job that runs at 18:00. Refer to schedules.



  • No labels