Presentation slides, video and FAQs available from DIP open day
We have now made the presentation slides and some FAQs available from the DIP open day that took place on 20 May. The event was designed to provide an overview of the onboarding journey, operation and road map and platform demo.
FAQs
Q: Testing should include qualification testing as well as SIT and UIT (testing stage of the DIP onboarding slide)
Answer: Agree Qualification testing fits within the UIT environments and we can make this clearer.
Q: Will the pre-boarding webinars be SIT/Non-SIT route specific? Esp with M10 ready participants around both of the dates shared- 1 July and 2 September?
Answer: We can make it clear through guidance where there are differences at the events in July and September
Q: The programme NFRs specify that our systems must be capable of handling a 72-hour outage. What is the recovery plan for this scenario?
Answer: We will work with our Market Design and MHHS Programme Design areas to confirm how we are orchestrating to the return of normal service
Q: For suppliers placing reliance how do we differentiate between our responsibilities and our services provider’s responsibilities as we onboard to the DIP
Answer: Overall, suppliers remain responsible for communicating and coordinating with the party on which they rely to understand progress. However, they recognise that the question is on the steps for the pre-onboarding phase and the testing phase for onboarding, and where the activity sits. The DIP team will modify the presentation to identify where the activity is most likely to sit.
Q: Is there any expectation post-MHHS to review and renew our DIP access?
Answer: Not now, the DIP Manager may decide in the future to utilise a version of re-onboarding as an Assurance Technique, but for now this is not in scope.
Q: Once DIP is restored, will some messages be prioritised? Will you stagger inbound and outbound messages? 72 hours of consumption data for 32m MPANs is substantial.
Answer: The scenario here is if the actual DIP service is down for 72 hours. We can confirm a Stop feature has been designed, but recognise there is a need to advise how such a scenario will be orchestrated.
Q: Onboarding – Using DCP/ 3rd parties – Is this approach possible with multiple third parties?
Answer: Yes
Q: Once the DIP production environment is live, is there any intention to complete any form of smoke testing? If so, when is this scheduled to commence?
Answer: Yes. The earliest this will commence is in August. Details on how will be advised.
Q: Will SIT participants need to do further onboarding?
Answer: At present, we are undertaking a data reconciliation activity of the data in SIT and comparing it against QAD data. There are numerous inconsistencies between the two. A reconciled set of data will be imported in UIT, and this will be where the master data of the data resides before it’s moved into production.
All SIT parties will be sent an invite to onboard into UIT, where they will be asked to confirm their data set-ups and DIP IDs, including any DCP setup. They do not have to undertake sandbox testing but it is recommended.
Where companies need to take action against their setups, i.e., the data in SIT does not match their QAD, they will be contacted and directly informed of the issues, and will be asked to take appropriate action.
Q: Will the enduring testing be isolated to DIP Manager team or including participants?
Answer: Inclusive of participants.
Q: Is there a list of Tasks to follow if you’re an MPID which uses a DCP approach? i.e. separate normal DIP on-boarding Task list.
Answer: We will provide the onboarding responsibility summary for our July and September events to help show the tasks that sit with DCP, whilst responsibility for ensuring the DCP completes its tasks sit with the Supplier. For further information about the webinars please contact [email protected]
Q: Create API credentials – where do we create these please? With Generating CSR – Is there a guidance for the values to be used for CSR? let’s say key strength.
Answer: Please see DIP on-boarding guidance PowerPoint slides.
Q: How does the code body and DIP manager journey tie into the service activation process (it’s mentioned at step / box 5)
Answer: The DIP Manager and Code Body journey denotes the work completed during and after code qualification, the DIP manager is informed by the Service Activation team of the appropriate Effective From Date (EFD) that the new DIP User has agreed upon.
The DIP user will be required to complete their Promotion to Production activities and continue their Service Activation journey. Although tasks are likely to run in parallel, Promotion to Production and Service Activation should be considered as different streams of work.
For further information about Service Activation, please refer to the slides that were presented at the MHHS Open day
Q: Could you please share your checklist for the DIP Manager to sign off for a participant to use DIP?
Answer: In the first instance we would direct you to the Qualification Overview page.
This provides information on the acceptance criteria for having the evidence to demonstrate able to operate on the DIP.
Q: Will it be a separate DIP portal to SIT?
Answer: DIP Portal in Production is different to the DIP Portal in other environments. Colour coding helps to identify which environment you are in.
Q: If a supplier is placing reliance on another’s testing, will they only need to onboard to Production – and no other environments (SIT, UIT environments)?
Answer: No, they need to onboard to UIT to confirm their setup – DIP IDs, roles DCP IDs, and they also need to perform their GS registration.
Q: If we have more than 1 MPID, do we need to create additional MPID configurations on UIT before promotion to production?
Answer: This will be done for you. You will need to follow the guidelines produced.
Q: Non-SIT LDSO have deadline of 30 May to onboard to DIP. Are you saying we will have to do this again in production, and if so, when? Why a pre-prod onboarding?
Answer: When you onboard to production it is a much reduced set of instructions as it does not include GlobalSign registration. Guidance will be going out within the next couple of weeks on what the Promotion to Production includes
Q: Will UIT and Prod share the same DIP Portal?
Answer: The portal looks the same, except they have a different colour in the banner.
Q: What are the steps that a SIT participant will need to take to onboard to the Production environment through UIT?
Answer: Guidance will be provided by the 20th June covering Promotion to Production, we will ensure it is validated by the MHHS Programme due to it being an integration phase from programme to M10.
Q: Why can’t the programme send a pub-47 to test a participant’s certificate setup in prod rather than the participant having to use the API to register webhooks?
Answer: Webhook set-up covers the DIP technical needs. The production environment is not expected to perform business testing, but it would be best directed to the MHHS Design Team if this needs further debate.
Q: What are the dates for prod onboarding?
Answer: A timeline working backwards from EFD and PABs is deemed beneficial. The DIP manager is working with internal teams to produce this.
Q: When is the earliest a participant can have their service activation complete?
Answer: For information about Service Activation, please refer to the slides that were presented at the MHHS Open Day.
Slide 32 denotes the Service Activation Journey.
Q: Has the team put Controls and governance in place to support ‘safe’ offboarding and moving MPIDs etc.
Answer: The DIP Manager has controls in place to engage with code bodies and will not make its own decisions to offboard. Engagement between the DIP Manager and Code Bodies to agree on these controls is taking place in June 2025
Q: At what stage do we get access to Atlas to manage our global sign registration? Will there be a walkthrough of how this will work?
Answer: Please see DIP on-boarding guidance PowerPoint slides
Q: Will the DIP Manager produce any performance reporting about parties?
Answer: Not at an individual party level.
The DIP Manager will provide overall performance summaries and where necessary will engage directly with a participant if there are performance discussions required.
Q: Are the performance reporting requirements for participants available? Do participants need to generate any reports on their systems to submit to the DIP manager?
Answer: Yes.
It will be available for Production. Confirmation on use in the SIT environments will be checked. No requirement for participants to generate reports to submit, the DIP Manager will have access to reporting for participants’ performance. For example, please see the Assurance slides that were presented during the day.
Q: Are there any key dependencies related to ‘service management’ arrangements, whereby they are required to be in place ahead of the DIP going live, participants being onboarded, and/or service activation being completed?
Answer: Yes, and the DIP Manager is coordinating with our Supplier and Elexon Service Management to be Production ready for Production Services at the right time.
Q: Under service activation bullet points, what does EFD stand for please?
Answer: Effective From Date
Q: How does DCAB tie into with Service management CAB? Or not?
Answer: It does not. It is essential to recognise the DIP Change Advisory Board is not part of operational change release management. Release management decisions with Service Management and Suppliers will be in a forum outside of DCAB.
Q: How exactly is the DIP funded?
Answer: Through annual business planning a forward look on change and operational costs are presented.
Current charging is recovered through the MHHS programme post programme completion the approved model is through market share based on MPANs utilising existing Elexon cost recovery services.
Q: Funding answer not clear: who pays? Suppliers only or all participants?
Answer: Suppliers
Q: Have participants been told how much DIP is going to cost them in the next 5 years per MPAN?
Answer: A MPAN cost level has not been provided and it is recognised volume of MPANs will change outside of annual business planning windows.
Q: To clarify, SIT participants will need to register on uit dip portal to get their prod DIP ID’s, even if they choose not to setup an environment for uit?
Answer: Correct
Q: Is there a process to submit enhancements for the DIP portal?
Answer: Yes
Change requests relating to the DIP portal can also be submitted via the DIP Change Process. Please refer to the Change process advertised on the DIP Website.
Q: Smoke test, proposal is to use API. We can’t test in SIT as we are using webhooks for SIT. Without an env to test against, first time to test API will be Qual onboarding – risk to onboarding if no API test environment available.
Answer: If you’re functional testing in SIT, using the webhook API in UIT would be the way to go.
Q: We will need MDR role if we are using our Supplier DCC role to gain consumption data? Is this also required for Qualification testing?
Answer: Please consult design team [email protected]
Q: If the MDR is non-active – do, we need certificates producing?
Answer: Certificates are not role specific
Q: Do we need to create different atlas certificates and API keys for each MPID if we operate more than one?
Answer: GS certs are per organisation (these need API keys). Additionally, there are different API keys at DIP id level.
Q: Is there anything participants that need to do for onboarding for sending messages to the DIP? Onboarding process documentation seems to be focussed on participants receiving messages.
Answer: No specific activity is required for sending message
Q: Would a DIP CR also come via ServiceNow as part of MHHS Elexon service management?
Answer: We will accept requests for changes to come via ServiceNow and using the contact details will ask for the requestor to complete the change
Q: Is the list of DCAB constituent reps published?
Answer: Yes – please refer to the DIP Website
Q. Not for onboarding, but for DIP enduring – for Industry SLAs, what’s being monitored on DIP side? What info is sent to REC/BSC? Who/what is enforcing the SLAs? e.g. within 60 mins an I/B flow must be processed and return an O/B response.
Answer: Please refer to DSD002 Annex 2 operational requirements.
Please refer to specifically section 11.3.
Q: DIP portal: Look- up and Replay functionalities: how far back does that go? Also, what user type can access these?
Answer: The MHHS Collaboration Base has a DIP Portal Guide. Section 3 covers Replay and requeue and indicates messages are retained for 30 days and is under the Market Participant Message Admin role.
Q: The swagger details look like programme scripts who in an organisation is this aimed at. Is it an engineering capability? And assume if placing reliance, it’s their responsibility for adjusting APIs and interpreting impacts.
Answer: Everyone – From BAs, SAs & development teams
Q: We are trying to assess volume of DIP messages we will receive or send for our portfolio of MPANs. Have you made assumptions at your level that you could share? e.g.: change of MS appt = LDSO receives/sends 9 DIP messages.
Answer: Please consult MHHS design team.
Q: Is the plan to display code change (BSC / REC) changes to the Swagger in the same way as DINs post go-live?
Answer: Yes
The version control will refer to the DIN / CP / Mod references which has triggered the change to swagger.
Q: Are these performance reports within the DIP portal covered by SIT-Ops tests?
Answer: The MHHS programme have confirmed DIP Portal Performance Reports are being tested in SIT Ops Theme 3, which is due to start on 9 June.
If participants have any further questions, it is suggested to contact the SIT Ops test lead using the following email [email protected]
Q: Where reporting (eg av latency) for all organisations, from here, can you drill down by organisation as a participant or is this static only/locked only to your performance?
Answer: Participants will see their reporting and the average of all other DIP Users. If a participant operates more than one DIP ID then they will be able to drill into any of their own DIP IDs.
Q: What does latency mean and how does it link back to DIP rules?
Answer: DIP Latency is the time taken for the internal DIP processing from receiving the message to addressing Recipient Latency is the DIP Latency in addition to the time it takes for recipients to respond, including any requeues and retries.
This is associated with the DSD operational performance sections.
Please refer to DSD002 annex 2 and specifically section 11.3.