SAP landscape and

Solution Manager CHARM

Quick card and procedures summary

26 October 2020

1
System landscape presentation

2
 Landscape (i) (standard one)
*70 *60 *50 *40
(APO,SRM, (APO,SRM, (APO,SRM, (APO,SRM,

GTS, BW) GTS) GTS, BW) GTS, BW)

CHARM CHARM CHARM

E70 E60 E50 E40

Periodic TMS Job

Xi/PI Xi/PI Xi/PI Xi/PI
B2B B2B B2B

REMARKS: E52
• B2B system is only available in E70 an E50 for non prod
systems. E60 has NOT B2B connectivity E54
• E52 may be switched for different roles depending on
the project (or other or both)
• On the sake of readability of this slide, some systems C52 (APO)
such as GRC have been omitted
• On October 2020 there is no availability for B52. IT’s
expected to be available beginning of 2021 *54
(APO,SRM,

BW)
3
Landscape (ii) (hot maintenance)

*71 (APO,SRM, BW) (associated *40

(APO,SRM-71, systems depending on the one (APO,SRM,

GTS) used GTS, BW)

E71 E52 E40

REMARKS: Xi/PI
B2B
• Hot maintenance to be used during the frozen periods of
system upgrades
• E71 always used as development system.
• For test system E52 to be used
• Only P1, Business legal requirements or urgent topics
are included on the Hot maintenance line under previous
approval.

4
Landscape (iii) (Sandbox)

*80 *70
Data source.: System refresh from *70
(APO,SRM, (APO,SRM,

GTS) GTS, BW)

E80 E70

Xi/PI
Xi/PI

REMARKS:

• Sandbox systems not connected in terms of transports with any other

system
• Used for
• Preliminary upgrade sanity check
• Preliminary test of third party add-ons
• Usual Sandbox operations (BF activations or other non reversible tests
• Prior to be used in projects needed to be checked if refresh is needed (refresh
data source : *70 system)

5
Solman golden rules quick card

6
 Systems changes flow
*70 DEV *60 QAL *50 REG *40 PRO
Standard release flow

Standard release change flow (mass import)

Changes in status “Change release” or
“Approved to Production”or “imported in
production via preliminary transport
(mass release)
Action “Release Change” (mass release)

Action “To be tested

Development Integration test NRT

Production
Special UAT
Unit test UAT
transport flow

(interfaces and excepcional

Preliminary

cases

Action “Request preliminary transport” Action “transport in prod”

Preliminary change flow (individual import)

7
 Systems roles (i)
*70 : Development systems (E70, C70, R70, G70, V70, B70) :
• Role: Development/Customizing/Unit tests
• How changes reach the system: Direct changes when transport created from CHARM
Remarks: only one client 100 – Client 200 not to be used anymore

*60 : QA systems (E60, C60, R60, G60) :

• Role: Integration test/User acceptance test
• How changes reach the system:
• “Transport of copies” individually when ticket pushed to “To be tested”
• Import in mass just before the TEST (NRT) phase (bulk mode transport)
Remarks: Test in E60 to be done always when technically possible (example of cases NOT possible:
for B2B interfaces, not possible because the lack of B2B ecosystem. Also some Xi/Pi interfaces like
MES)

8
 Systems roles (ii)
*50 : Regression systems (E50, C50, R50, G50, B50) :
• Role: Non-Regression tests + Exceptionally integration/UAT for specific projects (e.g.
B2B interfaces involved)
• How changes reach the system:
• Import in mass just before the TEST (NRT) phase for tickets set to “Change
release” status
› Biweekly: 2 days before golive + sanity check in E50
› Quarterly: 3 weeks before golive + NRT Quarterly release testing in E50
• Via preliminary transport in exceptions approved by the Domain Lead for tickets
with “Request Preliminary import” action

Remarks: The fact that a ticket is preliminary transported does not prevent the inclusion of it when the
release is imported in mass. So the ticket will be included in the release and reimported in bulk mode
with the rest of tickets. See “preliminary transport” part

9
 Systems roles (iii)
*40 : Production systems (E40, C40, R40, G40, B40, V70) :
• Role: Production system
• How changes reach the system:
• Import in mass in release Deployment phase for tickets :
• Set to “Change release” status
• Set to “approved for production”/”Imported in production” for the tickets which were
preliminary imported . Also “retest successfully” for defect tickets
• Type “Urgent change” (ticket number starting by “2” imported during release
lifecycle
NOTE: Preapproved tickets (Charm STANDARD changes) are NOT reimported
Remarks: The fact that a ticket is preliminary transported does not prevent the inclusion of it when the
release is imported in mass. So the ticket will be included in the release and reimported in bulk mode
with the rest of tickets.
For tickets which were preliminary imported, if there was soft config associated to them, even
that in vast most of cases no impacts are expected to be found
it’s highly recommended to verify it

10
Additional test systems (i): E52
*52 : Test system (E52, C52) :
• Role: Test related to special project or dry runs (2 nd run) for data load exercises
• How changes reach the system: Automatic synchronization with E50 queue: System
will keep the same level of transports as E50
Technical Approach:
• When a release transport is imported into E60, it will remain in the queue of E50 and E52 (as per the
TMS configuration)
• A job will will run periodically (every 30 minutes) and will import the contents of the E52 queue
• Since the E52 will receive the ordinary transport orders imported in E60 an NOT the “transport of
copies”, this assures that only changes approved for Release -or with E50 preliminary- import will
come into E52 assuring the non-pollution of E52 with unfinished changes

CHARM CHARM CHARM

E70 E60 E50 E40

Periodic TMS Job

E52

11
Additional test systems (ii): E71/E54
*71 : Development systems (E70, R71) :
• Role: Development/Customizing/Unit tests in Hot maintenance special line. To be used
during the periods when the standard system landscape is frozen due to upgrade project
in progress
• How changes reach the system: Direct changes when transport created from CHARM.
Systems intended to create only changes related to urgent changes in frozen periods
*54 : Testing system (dedicated for BW4 Hana project) (E54, C54, R54, B54)
• Role: test system in special projects – Similar to E52
• On October 2020 this system is providing support to the BW4 for HANA project
• How changes reach the system:
• Either synchronization from E60 (same as in E52)

12
 Preliminary transports (i): How to
• Allow to transport in preliminary mode to Regression and Production system
• Individual tickets are advanced to *50 and *40. This import happens in two phases:
• To *50 : When Action set to “approve preliminary import” by Domain Lead approval or
delegated people
• To *40 (PROD): When "authorized for Prod” by domain lead AND performed by Basis
team. Approval from CoE Director neeed to be obtained prior to the transport.

13
 Preliminary transports (ii): Golden rule
IMPORTANT: REIMPORT : ALL Changes which were pushed in production via preliminary
transports will be still included in the release where they belong so they will be
reimported during the release deployment
• This is a standard SAP CHARM procedure and is needed to keep the
consistency of the release, not altering the group/sequence of the changes

SOFT CONFIG : In the event that the preliminarily imported changes would need some kind
of post import soft config in production, it’s recommended to cross check whether the
reimport may generate some impact on it.

14
 Preliminary transports (iii) - Remarks

• This action is advisable to be done when :

• Is not possible to test something in QAL *60 because technical constraints (e.g. B2B
interface related changes)
• A normal change becomes urgent and needs to be pushed to production in advance
• Some other urgency appears with a change
• This action is NOT advisable to be done when
• The change consists of a huge package : E.g., a project which needed to be delivered in
production out of release calendar: In this case, another approach may be taken
• When the objects of transports are prone to be numerous and subjected to frequent
changes for which intersection of versioning are expected to happen (e.g. mass roles
updates)

15
 Defects found during release
A defect detected during the TEST phase of the release cycle may be managed either:
a) Creating a “defect” ticket
• Special type of ticket which is possible to be associated only to release cycles
which are in TEST phase
• These tickets are managed with similar flow to the normal changes, with the
particular point that they can moved to regression individually

b) Setting a change to “on Hold”

• This is a special status which keeps the ticket out of the release even if it was
included in the pack to the regression system (and as consequence, part of the
release)
• Ticket is automatically pushed to the next release
• REMARK: Since this procedure alters the contents of the release after it has been
moved to regression is ONLY advisable to use it when there is no technical way
to overcome the defect and an impact is expected in production if change
included

16
Thank you

17