Page History

This Wiki page provides information related to the transport process during the SAP Support Pack 2023 project.   Further questions about this process can be directed to Elda Prudden, Transport Coordinator, at eprudden@mit.edu or 617-253-5153.

Key Dates

• SF2 unavailable - to be upgraded starting

• Sunday Oct

• 22 at 5pm until

• Wednesday Oct

• 25 at 8am

• SH2 unavailable - to be refreshed and upgraded starting

• EOD Tuesday Oct 24 at

• 23:59 until EOD Friday Nov 3 

• This year’s “restricted window” (i.e. when the transport path to PS1 changes and dual testing is required for critical production changes) starts when SF2 goes down on

• Sunday Oct

• 22 at 5pm and ends after SP2023 go-live weekend (Dec 1-3)
  

• The last normal transport to

• PS1 (until after Support Pack go-live) is Thursday Oct 26.  This would include any transports that have been tested in non-upgraded SH2 and approved between Oct 19 and Oct 24 for production deployment

• After Support Pack go-live, the normal transport to production schedule will resume on Wednesday Dec 6.

SAP Environments During Restricted Window

1. Those related to SAP support packs encountered in upgraded environments (e.g.

   Upgraded environments - SF3, SF2, SH2

   , SF3)
2. Those encountered in production (not upgraded environment)
3. Those related to projects/enhancements approved for migration before SP2023 go-live
4. Those related to projects/enhancements approved for migration during SP2023 go-live

Development/Transport Procedures

Transports to SH1 and Production during the restricted window will be limited to critical fixes that need to be moved to Production as soon as possible before the project go-live date.  

For the duration of the restricted development window  (10/20/2023-12/06/2023), a special process will be used for development of fixes to SAP. The aim of this process is to avoid the introduction of non-support pack changes into the Support Pack test system (SH2) or the Production system (PS1).

The following are the steps in the special development process.

Fixes for Support Pack related issues found during Unit Testing in SF2 or SIT in SH2

Development steps:

1. Change the development object(s) to implement the required fix.
2. Perform unit testing in SF2.
3. Release the transport(s) once unit tested
4. Create a ServiceNow 'test' deployment request, select 'Routine' as the 'Type', leave the 'State' as 'Pending', and send an email to the Project Manager, Kevin Lyons (klyons@mit.edu) who will change the ServiceNow request 'State' from 'Pending' to 'Work in progress'; additionally, the Project Manager will add a note to the SN request indicating that they approve the request.
5. When executing ZUTTREQ, make sure SH2 is the 'To' environment, and include the ServiceNow request number from step 4.
6. Include the ZUTTREQ details in the ServiceNow request as usual.
7. During SIT, transport the fix to SH2 and test to confirm the efficacy of the fix.

Transport request procedures:

Send an email to the Project Manager for approval of the ServiceNow ticket. 

After the necessary approvals have been given, the R3 Admin team (r3-chmgt@mit.edu) will move the transport(s) to SH2.

Transports generated during SF2 Unit Testing will be accumulated and moved as a group as part of the Support Pack application process to the SH2 test system after it is refreshed with a copy of production.
Transports generated during SH2 SIT will be imported as needed into SH2.

Transport path = SF2 -> SH2
Approver: Kevin Lyons (Project Manager)

Critical fixes for non-Support Pack related issues found in Production during SP2023

Before development is begun, it should be clear the business owner considers the problem is critical and requires an immediate fix. Send an email message describing the situation to the Project Manager, Kevin Lyons (klyons@mit.edu), with a copy sent to Elda Prudden (eprudden@mit.edu), to facilitate consideration of the critical fix. When ready to move to Production, the Project Manager will request approval from one of the business members of the Steering Committee.

2. Non-upgraded environments - SH1, PS1 (upgraded on go-live weekend in Dec)

3. SE1 (non-upgraded)

   1. While the support packs are being applied to SF2, SF2

1. 1. will not

1. 1.  be available for development. If an emergency arises during this period,

1. 1. SE1 will be used for development

1. 2. If a critical issue is discovered in PS1 that requires the application of an OSS note, SE1 will be used instead of SF3 for the application and testing of that note (production support path for OSS notes is SE1

1. 1. -> SH1 -> PS1

1. 1. ).  Additionally, scrutiny would then be needed to ensure that the OSS note is included in SAP's support pack.

Types of Transports/Changes During Restricted Window

Approvers to begin the development work:

• One of the business members of the Steering Committee
• Kevin Lyons (Project Manager), Olu Brown (backup)

The functional team needs to follow the standard QA Issue Resolution procedure, which includes the SAP mini-spec and associated test case documents.

Approvers for importing transports to production:

• Refer to QA critical transport procedures

These transports must be tested twice, once in the production support path (SF2 -> SH1), then in the Support Pack upgrade path (SF2 -> SH2), before the transport(s) can be imported into production.

Development Steps:

1. Change the development object(s) to implement the required fix in SF2 and then transport to SH1.
2. Perform unit testing in SF2 & SH1.
3. For testing the change as part of the Support Pack application process:
   1. Release the transport(s) once unit tested
   2. Create a ServiceNow 'test' deployment request, select 'Routine' as the 'Type', leave the 'State' as 'Pending', and send an email to the Project Manager, Kevin Lyons (klyons@mit.edu) who will change the ServiceNow  request 'State' from 'Pending' to 'Work in progress'; additionally, the Project Manager will add a note to the SN request indicating that they approve the request..
   3. When executing ZUTTREQ, make sure SH2 is the 'To' environment, and include the ServiceNow request number from step b above.
   4. Include the ZUTTREQ details in the ServiceNow request as usual.
   5. Transport the fix to SH2.
   6. Perform testing required to confirm the proper functioning of the fix in SH2 (as part of the Support Pack application process).
4. For testing the change as part of the critical production issue process:
   1. Create a second ServiceNow 'test' deployment request, select 'Routine' as the 'Type', leave the 'State' as 'Pending', and send an email to the Project Manager, Kevin Lyons (klyons@mit.edu) who will change the ServiceNow request 'State' from 'Pending' to 'Work in progress'; additionally, the Project Manager will add a note to the SN request indicating that they approve the request.
   2. When executing ZUTTREQ, make sure SH1 is the 'To' environment, and include the ServiceNow request number from step a above.
   3. Include the ZUTTREQ details in the ServiceNow request as usual.
   4. Transport the fix to SH1.
   5. Perform testing required to confirm the proper functioning of the fix in SH1
   6. Create a ServiceNow 'Prod' deployment request, as usual, including ZUTTREQ details, etc. 
   7. Obtain the required approvals.
   8. Transport the fix to Production.

Transport Request Procedures:

Note: for dual testing, the changes will need to be tested in both non-upgraded SH1 and again in upgraded SH2 to ensure expected behavior is found in both environments.

Transport procedures

1. For transports related to SP2023 Project

Create a ServiceNow ticket as usual (directed to SH2), except for the following SN details:

1. 1. leave the 'State' as ‘Pending’
   2. add Kevin Lyons as a watcher
   3. send an email to Kevin (klyons@mit.edu) asking for an approval (Olu Brown obrown@mit.edu as backup).

Create a ServiceNow ticket as usual (again, directed to both SH1 and SH2), except for the following SN details:

1. 1. leave the 'State' as ‘Pending’
   2. add Kevin Lyons as a watcher
   3. send an email to Kevin (klyons@mit.edu) asking for an approval (Olu Brown obrown@mit.edu as backup).

What to do in ZUTTREQ:

1. Check 'Critical'
2. 'To' environment as:
   1. for the Critical Transport path - SH1
   2. for the Support Pack path - SH2 .

After approval, the R3 Admin team (r3-chmgt@mit.edu) will move the transport(s) to PS1 and SH2 respectively.

Transport paths = SF2 -> SH1 -> PS1 and SF2 -> SH2
Approvers: see above

Ongoing Projects with planned install in Production with Support Pack Go Live

Will require regression testing in SH2 to confirm proper functioning with support packs.

Upon successful testing in SH2, these transports/changes will be deployed a second time to PS1 on go-live weekend, along with all the other SP2023 Project transports/changes (i.e. to ensure that PS1 is in synch with SH2 by importing the same transports in the same sequence as they were imported into SH2).