Advertisement

Technical Architecture Effort in S/4HANA

  • Sanket Kulkarni
Chapter
  • 897 Downloads

Abstract

Technical architecture considerations for SAP S/4HANA are far different than traditional on-premise ERP systems. The SAP S/4HANA stack is very much focused on the future, suited mainly for the digital transformation of your business. Technical architecture discussions in SAP S/4HANA implementation revolve around three aspects.

Technical architecture considerations for SAP S/4HANA are far different than traditional on-premise ERP systems. The SAP S/4HANA stack is very much focused on the future, suited mainly for the digital transformation of your business. Technical architecture discussions in SAP S/4HANA implementation revolve around three aspects.
  • Infrastructure aspects
    • Can SAP S/4HANA and the associated SAP stack be hosted on the cloud?

    • What are S/4HANA versions are best suited from an infrastructure perspective? Should you use the On-Premise Edition or Cloud Edition?

    • What are the storage and performance considerations?
      • With an optimized database, your storage considerations are going to be reduced compared with traditional ERP. Sizing helps you arrive at the appropriate number.

      • You would like similar or better performance than traditional ERP provides. What are new performance benchmarks, considering SAP UI will move to Fiori?

  • Migration aspects
    • You can implement SAP S/4HANA in three different ways. The choice of an implementation approach also affects the way you will migrate data to SAP S/4HANA.
      • Greenfield implementation.

      • Brownfield implementation.

      • Staged Brownfield (also called Bluefield) implementation.

    • SAP provides various tools to support S/4HANA installation and migration, depending on the implementation approach. You need to determine which tool is appropriate for your approach.

  • Security aspects
    • With Fiori, internal as well as external parties can access the SAP S/4HANA system. What are the security aspects for mobility and the Fiori UI, and in general for SAP S/4HANA?

High-Level Architecture

Let us first understand the high-level technical architecture of SAP S/4HANA. As seen in Figure 7-1, S/4HANA resides on the back-end SAP HANA database. The application layer in the middle is often called the S/4HANA core access database tables via CDS views. Transactional logic as well as logic for analytics functionalities (covered in Chapter  10) often resides the in S/4HANA core.

Please note that business logic resides in both the S/4HANA core as well as the HANA DB level, for faster reporting and retrieval. The SAP Gateway connects the SAP UX layer, including Fiori, to the S/4HANA core.

The end user accesses the SAP UX layer via SAP Web Dispatcher, which is responsible for routing user requests to the S/4HANA stack.
Figure 7-1

S/4HANA architecture

Please note that Figure 7-1 does not cover associated on-premise as well as cloud-based SaaS components that might be present in your SAP landscape. Apart from non-SAP legacy systems, you might have separate instances for other SAP systems such as SAP APO or CRM. Such systems will be integrated to target the SAP S/4HANA instance eventually.

SAP provides a set of tools to integrate the SAP S/4HANA On-Premise and Cloud editions with legacy applications that are not part of the SAP S/4HANA suite. SAP HANA Cloud Integration (HCI) is the preferred process integration middleware. Tools like SAP Landscape Transformation Replication Server (SLT) and SAP Enterprise Information Management (EIM) also facilitate data transfer. SLT is often used for real-time data replication sourcing from SAP ERP or non-SAP systems into S/4HANA, as in the case of Central Finance. EIM refers to the tools like IS and the Data Services platform, as well as PowerDesigner.

For example, if you opt for SAP S/4HANA On-Premise Edition, all SAP SaaS applications like Ariba and Concur will be integrated into S/4HANA via HCI. SLT/EIM tools become relevant in the case of Central Finance and MDG implementations.

Your technical architecture considerations for SAP S/4HANA should include such integration aspects with SAP and non-SAP S/4HANA systems along with necessary tool sets (HCI, EIM, SLT).

Technical Architecture Assessment

Once you have a clear understanding of the target SAP S/4HANA stack, it is time to prepare the SAP bill of materials (BOM), a list of SAP systems in your landscape. This list will further drive not only the technical architecture discussions, but also licensing and cloud procurement as well.

You can start a technical architecture assessment once you have the final SAP BOM. You will do it during the early days of the SAP S/4HANA project, in conjunction with the planning phase.
  • Technical architecture assessment decides on various important topics such as datacenter strategy.
    • Where are your primary and secondary (backup) datacenters located?

    • What is your HA/DR strategy?

    • What is the availability SLA for datacenters?

  • Scalability requirements
    • What are your sizing requirements in terms of storage and performance?

    • Which environments are hosted on the cloud? Is it going to a public or private cloud instance? How are cloud virtual machines (VMs) provisioned: on-demand or fixed capacity?

    • Are there any security requirements?

    • Are there any data privacy requirements (e.g., GDPR)?

  • Change management landscape
    • What is my SAP deployment landscape? Does a three-system landscape—Development ➤ Quality ➤ Production—suffice, or do I need a more complex one?

    • If you are running an SAP ECC/ERP production instance in parallel while SAP S/4HANA goes live, what is your retrofit strategy? How will changes in the SAP ECC/ERP system flow to SAP S/4HANA during the project life cycle?

Datacenter Strategy

Datacenter strategy revolves around careful evaluation of your HA/DR and backup and restore processes. You might need to provision additional hardware capacity for proper failover and restore functions with defined availability SLAs, define node and site failover, and appropriately restore capabilities.

Suppose you have two datacenters—let us call them DC1 (primary) and DC2 (secondary)—along a with remote datacenter. Your datacenter strategy will revolve around synchronous replication between DC1 and DC2 and asynchronous replication to the remote datacenter.

In such a case, you have two alternatives:
  • Combined HA/DR protection within DC1 and DC2.

  • Storage system only in highly protected DC2.

Such an arrangement makes sure that there is no data loss when a link to DC1 is lost. It also reduces the probability of data loss in the case of disaster with DC2. That way, you have local failover within the datacenters for hardware and software failures. The application server and SAP hardware in DC2 can also be used for nonproduction systems.

In summary, your datacenter strategy for SAP S/4HANA will be dependent on the choice of infrastructure (DC network).
  • For low-latency, stable inter-DC network:
    • Host-auto failover with synchronous storage replication.

    • Host-auto failover with synchronous system replication.

  • For the limited interDC network:
    • Host-auto failover with backup and log shipping.

Scalability Requirements

Scalability and performance constitute a big consideration for your SAP S/4HANA project. It is not only driven by simple memory and storage considerations, but also by performance considerations. There are three scenarios in which you can run S/4HANA sizing with the QuickSizer tool.
  • Greenfield S/4HANA sizing.

  • Sizing based on the existing SAP ERP system.

  • Sizing based on existing SAP system working on HANA Database.

You can also add specific performance benchmarks as part of the sizing exercise. Here are some examples.
  • Can SAP S/4HANA process more than 3 million orders in less than two hours?

  • How can I consolidate five functional ERP systems into one?

  • How can I migrate 10 TB of SAP ECC data to S/4HANA?

Note that translating business requirements into sizing requirements is an iterative process and thus needs to consider a variety of angles, including commercial considerations. For example, you can also look at business growth, mergers in the pipeline, or large functional extensions from a sizing perspective. Such business parameters might or might not affect all sizing components. Clarity on the impact of respective factors on sizing components is important and drives sizing decisions.

For example, you are experiencing substantial business growth and would like to know how it affects SAP S/4HANA sizing. A simple table, like the example shown in Table 7-1, will provide clarity on the impact on sizing decisions.
Table 7-1

Example Sizing Evaluation Table

S/4HANA Sizing Component

Affected by Business Growth

Operating system

No

HANA caches/services

No

HANA working memory

Yes, indirectly

Business data (Columnar Store)

Yes

Metadata (Row Store)

Partially, if growth affects DDIC entries in the metadata

The output of the sizing exercise is the capacity recommendations for PRD (Production) and non-PRD (non-Production) S/4HANA landscape, in terms of memory size, disk size, and CPU (related to memory).

Change Management Landscape

Change management landscape covers the SAP S/4HANA production as well as nonproduction landscape. You will also consider the PRD and non-PRD landscape, including software change management and non-PRD sizing.

After the sizing assessment, you evaluate various deployment models; for example, you might opt for standard deployment for production and virtualized deployment for nonproduction systems. Table 7-2 illustrates a variety of S/4HANA landscapes. Note that variations might exist owing to the specific considerations of retrofits or coexistence of production and project environments, for example. Industry considerations can also drive the choice of the landscape; for example, the pharmaceutical industry will need a computer system validated environment for testing and production.
Table 7-2

S/4HANA Landscapes

Landscape

Description

Environments

3-system landscape

Applicable for moderately customized S/4HANA implementations

Development ➤ Quality ➤ Production

4-system landscape

Applicable where additional test cycles are needed; for example, validated testing in the pharmaceutical industry, or performance testing in high-data volume environments

Development ➤ Quality ➤Testing ➤ Production

5-system landscape

Applicable where production and project track run in parallel; for example, you have already gone live with pilot site and then rolling S/4HANA solution in other sites

Development 1➤ Quality 1 ➤ Production

Development 2➤ Quality 2

The higher the number of customizations while implementing SAP S/4HANA, the more complex your SAP landscape will be. You will need to test more, expend more effort during deployment, and devote more time to support as well.

S/4HANA Migration

There are three different ways in which you can implement SAP S/4HANA. Your choice of implementation approach affects technical architecture decisions such as tools to be used and steps to be followed for conversion. Please note that I am using terms such as conversion and migration interchangeably. In principle, it means the transfer of data and customizations from the source SAP ERP to the target SAP S/4HANA version.
  • Greenfield implementation
    • It involves the plain “vanilla” installation of S/4HANA on a hosted environment.

    • Data migration is done using tools such as Data Services. You create customization from scratch or manually lift-and-shift from the source ERP system in specific cases. Refer to Chapter  5 for more details on data migration for Greenfield implementation.

  • Brownfield Implementation
    • It involves the plain “vanilla” installation of S/4HANA on a hosted environment.

    • Data, as well as customizations, are migrated using a set of tools provided by SAP.

  • Staged Brownfield (Bluefield) implementation
    • This relatively new approach is a variant of a Brownfield implementation where you migrate customizations up front and migrate data in batches.

    • It is suitable for scenarios where you are deploying SAP S/4HANA in stages; for example, across regions in multiyear rollout programs.

Because the technical architecture plays a major role in SAP S/4HANA conversion during Brownfield implementation, we discuss only the key aspects in this chapter. Please note that I have skipped most of the technical details, as you should refer to the respective SAP guides for step-by-step implementation.

Step 1: Establish Prerequisites

This step makes sure that all of the following preconditions for installing SAP S/4HANA are met.
  • The source SAP ERP must be a Unicode-enabled system. SAP does not support Unicode conversion during the migration to SAP S/4HANA. If your SAP ERP is not Unicode-enabled, it should be enabled first, then migrated to SAP S/4HANA. This is often called a two-step process. If your ERP is an older SAP Business Suite release, you should upgrade it to SAP ERP 6.0 EHPxx first before considering migration.

  • Migration to SAP S/4HANA does not require source SAP ERP already on HANA DB. SAP Migration tools take care of any DB to HANA DB conversion.

  • Migration can happen only from ABAP Stack Application Server. Your SAP Application Server might be dual stack (ABAP as well as Java Stack). Some organizations favor a dual-stack approach where they can do any process customization on ABAP, and the Java stack is used as a wrapper for using SAP NetWeaver components like Portal/ITS. You should split a dual-stack architecture before you go ahead with SAP S/4HANA migration.

  • If you are already using Fiori, and thus have a Fiori front-end/gateway server, it should be connected by the new SAP S/4HANA system via a hub-deployment model. Existing Fiori apps will continue to run as if they are connected to the older back-end system. For the connection to the S/4HANA back end, the Fiori Apps should be redeployed and configured.

Step 2: Prepare for S/4HANA

This step involves multiple checks to be run in conjunction to assess S/4HANA migration impact and take corrective actions if needed. Maintenance Planner is used to check the following components.
  • Any add-ons to your system.

  • Any active business functions in your system. Note that if you have a certain business function in an always-on state in the source SAP ERP that is to always be off in SAP S/4HANA, it causes a potential conflict during migration.

  • Industry solutions.

Maintenance Planner can flag such components for attention if it finds that there is no valid conversion path for them. If the Maintenance Planner check is successful, it generates the files necessary to download (add-ons, packages, and the stack configuration file) for migration. Key information is populated in the stack configuration file (stack.xml) to be used by Software Update Manager (SUM), a tool responsible for SAP S/4HANA migration.

An SAP readiness check for SAP S/4HANA is run to check several aspects related to SAP S/4HANA implementation. The precheck tool validates installed software components and checks functional requirements as well as usage of business functions. The simplification database checks the impact on the custom code by simplification items.

As covered in Chapter  4, custom code changes in a Brownfield implementation are not just related to database (as in from any DB to HANA), but also related to the functionality as well as a performance optimization.

With the simplification of the SAP standard code, a lot of standard objects were modified, joined, or decommissioned. They have a direct impact on the custom code, relying on SAP standard objects. This analysis calls out each SAP standard object that could have an impact on the custom code, often referred to as simplification items.

You can use either of the following tools during SAP S/4HANA migration.
  • The simplification item list is a PDF document that describes the change and the expected impact for each simplification item.

  • The simplification item database is a tool-based analysis approach that compares the actual simplification item list with the source ERP system based on an extract of the custom code metadata.

Beside of the adjustment of the custom code to meet the simplification item requirements, there is still the need to ensure that the custom code is running functionally correct on an SAP HANA DB. SAP tools present the analysis in the following four main categories:
  • Mandatory changes to ensure functional correctness.

  • ABAP-based changes to ensure no performance degradation.

  • ABAP-based changes for performance optimization.

  • DB-based development (code push down) for performance optimization.

Please note that it is good practice to adjust all DB independent mandatory changes in the source system to reduce the effort required and duration for the migration project. You can also run usage analysis in the source SAP system to pinpoint frequently used custom objects and fix them specifically for SAP S/4HANA migration. That way, the effort needed for custom code remediation is optimized.

Step 3: Complete SAP S/4HANA Migration

This step starts with the activation and deactivation of business functions identified in Step 1. You execute the functional prerequisites in terms of necessary add-ons and industry solutions. The

The stack file (prepared by Maintenance Planner) is now ready to be used by SUM. The SUM tool starts by cleaning up noncompatible add-ons or any third-party tools. Then, it begins the installation of SAP S/4HANA and then executes the Database Migration Option (DMO) to migrate the necessary configuration as well as data to the new SAP S/4HANA instance.

Please note that you have other advanced options to migrate data and configurations to SAP S/4HANA. A few of them are listed here. You can check for further details in relevant SAP documents.
  • SAP DMO: SAP direct migration to HANA (combining migration with upgrade).

  • SAP Downtime Optimized DMO: Migrating specific application tables during uptime to minimize downtime.

  • SAP Near-Zero Downtime (NZD): Minimizing downtime for business-critical environments.

  • SAP Landscape Virtualization Management (LVM): Automate post copy and migration steps.

You should also check whether there are any follow-on activities for specific functions, for example, finance. Finally, you should do custom code remediation by implementing any mandatory changes (database as well as functional), followed by rigorous testing (functional unit testing). Further, you have to adjust the custom code related to simplification item lists and test it thoroughly.

Once completed, you have a fully migrated SAP S/4HANA instance for Brownfield implementation. Please note that the impact on existing interfaces by SAP S/4HANA migration is minimized by SAP ensuring backward compatibility with the data model on traditional databases. It should therefore not affect all the interfaces, but it would make sense to test all interfaces during SIT.

S/4HANA Migration in Four-Tier Landscape

Suppose your source SAP ERP is on a four-tier landscape, such as Sandbox ➤ Development ➤ Quality ➤ Production. If you want to migrate to a four-tier SAP S/4HANA landscape, you should execute the following steps.
  1. 1.

    Start by preparing the SAP ERP sandbox system as a copy of the production system.

     
  2. 2.

    Run Maintenance Planner, prechecks, and custom code checks in the Sandbox system of the source SAP ERP. Maintenance Planner will subsequently create a stack file based on the analysis.

     
  3. 3.
    Run SUM data migration, along with a software update, in the Sandbox system. Follow-on activities for Finance are complete. Perform custom code remediations (SPAU/SPDD) along with any delta changes. The SAP S/4HANA Sandbox system is ready for use now.
    • The purpose of this exercise is to establish the steps and time taken for SAP S/4HANA migration.

    • It also highlights any issues like data inconsistency or business function conflicts up front.

     
  4. 4.

    Set the SAP ERP development system to Code Freeze, which means no further changes are allowed until migration. Execute Maintenance Planner, prechecks, and custom code checks, and generate a stack file for the development system.

     
  5. 5.

    Execute SUM data migration, along with a software update, in the development system. Follow-on activities for Finance are complete. Perform custom code remediations (SPAU/SPDD) along with any delta changes. The development system is ready with steps and time taken for SAP S/4HANA migration validated.

     
  6. 6.

    Refresh the SAP ERP quality system with production data. Execute Maintenance Planner and prechecks. Note that the quality system will also have a similar Code Freeze restriction during migration. Then, generate the associated stack file.

     
  7. 7.

    Execute SUM data migration, along with a software update, in the quality system. Follow-on activities for Finance are complete.

     
  8. 8.

    Import transport requests related to custom code remediations (SPAU/SPDD) along with any delta changes, into the quality system. Now, your quality system is ready with steps and time taken for SAP S/4HANA migration validated.

     
  9. 9.

    Execute Maintenance Planner and prechecks in the production environment and generate a stack file.

     
  10. 10.

    Execute SUM data migration, along with a software update, in the production system. Follow-on activities for Finance are complete. You import transport requests related to custom code remediations (SPAU/SPDD) along with any delta changes, into the production system.

     
  11. 11.

    Finally, your SAP S/4HANA production system is ready with complete configuration and data migrated successfully.

     

Security

The objective of SAP security is to protect the SAP S/4HANA installation by maintaining its confidentiality, integrity, and availability. The guiding principle of SAP S/4HANA authorizations is that every user should have access only to the information and resources that are necessary for a legitimate purpose. You grant only the privileges that are essential to do the user’s work within SAP S/4HANA. Often termed least privilege, this is a principle-based approach, not an absolute rule. There will be instances where the benefits of applying the least privilege principle will not outweigh the risks of granting additional access privileges.

The SAP S4 HANA authorization concept involves the assignment of general as well as detailed user authorizations to the user master. These assignments can reach down to the transaction, field, and field value levels. Actions by a user might require several authorizations. For example, to change a material master record, authorizations are required for the following:
  • Transaction “change.”

  • Specific material type.

  • Views of the material master record.

  • General authorization to work with the company code.

Such authorization requirements often require deliberate effort from SAP security teams to build a complex relationship between authorization objects and fields, often called building blocks for SAP security design. Figure 7-2 shows the hierarchical relationship between various aspects of SAP security design.
Figure 7-2

SAP security building blocks

  • Authorization field: This is the smallest unit against which you do the authorization checks. The fields in an authorization object contain permissible values in specific data elements. During authorization checks, SAP validates such values against the input. If satisfied, then access is given only to the user.

  • Authorization object: An authorization object groups all related authorization fields necessary for authorization. All the fields are checked simultaneously for user access.

  • Authorization object class: This is where you combine authorization objects into logical groupings of authorization objects.

  • Authorization is the authority to perform an action in the SAP system based on a set of authorization field values in an authorization object or class. Each authorization refers to exactly one authorization object and one or more possible values for each authorization field listed for that authorization object.

  • Authorization profile: This contains authorizations for different authorization objects. User authorizations are assigned using authorization profiles.

  • Single role: A role is a set of functions or transactions describing activities done by the user.

  • Composite role: Also known as a collective role, this is a group of several different (single) roles. Note that composite roles themselves do not contain authorization data. If an authorization change is required in a composite role, the authorization data must be maintained in the (single) roles.

SAP Security Design and Build

As part of the SAP S/4HANA implementation, you design the security roles in a manner that supports compliance objectives of your organization. Security role design should be efficient to maintain and enable the least privilege principle stated earlier. The SAP Profile Generator (PFCG) is used to create roles and generate profiles. With the Profile Generator, you define the roles for various job functions, with allowed activities. It then serves as a link between the user and the corresponding authorizations. The Global Role transaction requirements are used as the basis to build all the end-user roles. Role creation and profile generation are done in the SAP S/4HANA development system and moved as a transport to the production system after testing. You assign these roles to users in the production system.

When maintaining security roles, authorizations, and profiles, you should follow these steps.
  • You capture the Global Role transaction requirements during the analysis phase. The requirements outline the transactions and are categorized based on the business processes, subprocesses, and activity level, such as a display change.

  • The Security Team maintains roles using the Profile Generator (transaction PFCG). In the PFCG, the roles are created to correspond to the process requirements. You add the tasks (reports and transactions) that belong to the related job function to the role menu.

  • You define the activity level for each transaction on the Authorization tab for each role. Additionally, you add the organization level values as appropriate. The PFCG automatically builds the authorization profile that applies to the role.

  • The roles are checked for segregation of duties (SoD) conflicts, tested, and then transported throughout the landscape and to production.

  • You update the user assignment and generate a profile in the user master records.

SAP Role Types

SAP security roles are a collection of related activities and permissions stored together. From a usage perspective, you categorize such roles into several role types.

Master Role

A master role is a template containing the most granular collection of security restrictions (transaction code) that will eventually make up an end user’s access in the SAP system. The master role does not define where (e.g., locations or data sets) you perform such transactions, so you do not assign them to the users directly.

Derived Roles

Derived roles are copied from the master roles to provide further restrictions on “where” you can perform a transaction (i.e., company code, plant). Derived role transactions and authorizations are inherited from the master role, but include additional restrictions identified in various organizational level fields. The transaction codes inherited from the master role restrict what a user can access.

A derived role is dependent on the master role. All transactional and nonorganizational field authorization values inherit from the master. You should maintain multiple roles (based on the master) with unique organizational field-level authorization values at the derived role level.

Single Role

Single roles contain common transactions used widely within the SAP environment that are not specific to a business process. Single roles can also be roles that have restricted transaction codes that only selected users will have access to, mainly for support if needed. Examples of these roles will be for security and BASIS support and emergency access roles.

Composite and Business Roles

These are a collection of derived and single roles making up a “basket” of functionality assigned to an end user. In the context of SAP security, the term business role is commonly used to associate a collection of single roles making up a position that could be assigned to end users. It is relevant for defining security roles applicable across multiple SAP systems. For example, a procurement-related role could include access to SAP S/4HANA, SRM, and portal.

There are two ways in which you can design the role types introduced here.
  • Create a task-based role design where the small, modular role is applicable for a group of tasks the user is expected to perform; for example, purchase order processing, or material master maintenance.

  • Create a job-based role design where roles are designed around jobs. Each job equates to one role, and that role provides all the access a user assigned to that job will need. For example, the purchase planner job role will include all the roles for purchase order processing as well as planning.

Table 7-3 gives a quick comparison of both role design approaches.
Table 7-3

Two Approaches to Role Design

Task-Based Role Design

Job-Based Role Design

Security is built based on small functionally definable tasks executed by a user (i.e., process cash receipts).

Security is built based on the job a user does (i.e., purchase planner).

A user might have more roles assigned, but there is a reduced risk of duplicate access.

A user gets a smaller number of roles; this increases the risk of granting functionality more than once.

Transaction codes required to complete the task are included in the same role.

Transaction codes and authorizations are duplicated in many roles.

User assignment is flexible; it is easy to grant additional access to only the tasks necessary.

Users might be granted more access than necessary because of “additional job” or backup responsibilities, thus there is less flexibility in role assignment.

Role maintenance is easier.

Role maintenance is often time-consuming.

Apart from the role design considerations already stated, there might also be a few additional restrictions that you want to enforce during security design:
  • Nonorganizational levels like document types and field values.

  • Organizational levels like specific sales or procurement organizations or plants.

Security for Nonproduction S/4HANA Systems

Nonproduction SAP S/4HANA systems often follow a simple role model that organizes access for the project teams. It is designed to be flexible yet maintains separation of the key functions. For example, roles for development access will be different from configuration access.

Table 7-4 lists some sample roles you will need to create in nonproduction SAP S/4HANA systems.
Table 7-4

Sample Roles for Nonproduction S/4HANA Systems

Role

Purpose

Configuration role

Full access to all the functional modules and configuration screens; they have fully functional access except for security, system administration, and ABAP development

BASIS role

Authorization to perform all system administration and standard BASIS functions

Security role

Authorization to create roles, generate profiles, perform role assignment, and perform user maintenance in the development environment

Development role

Authorization to perform all ABAP development and conversion activities as needed

Functional (Application) role

Authorization to use SAP user functions to simulate business scenarios for prototype and creating training materials; does not involve any authorization for configuration or security or BASIS-related tasks

Configuration + Functional + Developer role

Full access to functional modules, configuration screens, transactional data, and ABAP development

Training role

Authorization to full functional access related to end-user training

Additional References

Copyright information

© Sanket Kulkarni 2019

Authors and Affiliations

  • Sanket Kulkarni
    • 1
  1. 1.PuneIndia

Personalised recommendations