Software Downloads. The SAP Download Manager is a free-of-charge tool that allows you to download multiple files simultaneously, or to schedule downloads to run at a later point in time. The SAP Download Manager is an SAP standalone Java application. The latest version is 3.1.1patch1, released in March 2018. JRE version 1.7 or newer is.
In this SAP BASIS tutorial, we will discuss SAP Application Servers and their instances. You will learn about two main types of SAP Application Server instances and their architecture.
An SAP Application Server instance defines a group of resources such as:
- Memory
- Work processes
- Dispatcher
- Gateway
- Internet Communication Manager
for a single application or database server in SAP system. When the SAP application instance and database instance reside on the same hardware, it is then known as a “Central System” setup. When the application instance and database instance do not share the same hardware resources, then the instance is known as a “Distributed System” setup.
Advertisement
An SAP Instance is uniquely identified with a SAP system ID, known as SID (System ID) and an instance number (2-digit number) from 00 to 99.
Example:
System ID: ERD
Instance No: 00
Instance No: 00
Each SAP instance can be distributed over multiple hardware units. These units can be a separate server or host, virtualize, logical or physical partitions within the same server or host. An instance is configured through an instance profile. An instance is also called application server in the software-oriented view of the client server model.
In an SAP NetWeaver application, it must have minimum one application server and can have multiple application server instances. The SAP application server instances process any incoming user requests. If there is more than one application server instances, there is one main instance that contains 3 core services which is the message server, the enqueue server and a start service.
Advertisement
This main instance we called it Central Instance (CI) or Primary Application Server (PAS) instance which consists of 3 core services and other services process like ABAP dispatcher, gateway and ICM.
For distributed system, the 3 core services are separate in one instance and we called it ABAP System Central Instance (ASCS). The ASCS instance is used to manage locks, exchange any message and perform load balancing in the SAP system. There is no dialog process in ASCS instance.
Architecture of SAP NetWeaver Application Server for ABAP (SAP AS ABAP) is shown below:
The working process for SAP AS ABAP is as follows:
Message Server (ABAP MS)
Advertisement
It handles communication between distributed dispatchers in SAP ABAP system. This process is configured only once for each SAP system. One of the vital services in SAP for SAP startup.
Enqueue Server (ES)
The lock table mechanism in the system manages by enqueue server components.
Gateway (GW)
It enables communication between two SAP system or between SAP system and external systems. It exists once per application server and can also be installed as standalone gateway.
Advertisement
Internet Communication Manager (ICM)
It allows communication with the SAP system using web protocols such as http, https or smtp. There is exactly one ICM process per SAP application server.
ABAP Dispatcher
Consist of SAP Work process. It separately executes individuals function in SAP applications such as Dialog, Update, Background Work process and Spool Work process.
SAP Central Instance (CI) / Primary Application Instance (PAS)
In Central System, SAP Central Instance is consisting of Message Server (MS), Gateway (GW), Internet Communication Manager(ICM) and Dispatcher Process (Disp) and one or more Enqueue (Enq) work process. Now, SAP has changed the terms of CI to Primary Application Server (PAS).
For Distributed System Setup, where Message Server and Enqueue process on separate instance which on (ASCS), Central Instance (CI) and Dialog Instance (DI), the different is only on SAP profiles while the process are the same.
In summary:
CI/PAS = MS + GW + Disp + Enq + ICM
SAP Dialog Instance (DI) / Additional Application Instance (AAS)
Dialog Instance (DI) is an additional application instance on top Central Instance (CI). Normally we will be setting up DI on a different host.
But Dialog instance is only consisting of Gateway (GW), Internet Communication Manager (ICM) and Dispatcher Process (Disp) only. There is no Message Server and Enqueue Work Process.
DI instance will always start after CI instances start because it will depend on CI instance as the main instance where message server and enqueue server exist. Normally we setting up Dialog Instance for load balancing and to handle more workload rather than only have Central Instance. The new name for DI is Additional Application Server (AAS).
In summary:
DI/AAS = GW + ICM + Disp
--
Did you like this tutorial? Have any questions or comments? We would love to hear your feedback in the comments section below. It’d be a big help for us, and hopefully it’s something we can address for you in improvement of our free SAP BASIS tutorials.
Navigation Links
Go to next lesson: SAP ABAP and JAVA Stacks
Go to previous lesson: What is SAP NetWeaver?
Go to overview of the course: Free SAP BASIS Training
-->Important
The earlier SAP Application Server and SAP Message Server connectors are scheduled for deprecation on November 30, 2019.The current SAP connector consolidates these previous SAP connectors so that you don't have to changethe connection type, is fully compatible with previous connectors, provides many additional capabilities,and continues to use the SAP .Net connector library (SAP NCo).
For logic apps that use the older connectors, please migrate to the latest connectorbefore the deprecation date. Otherwise, these logic apps will experience execution failures andwon't be able to send messages to your SAP system.
This article shows how you can access your on-premises SAP resources from inside a logic app by using the SAP connector. The connector works with SAP's classic releases such as R/3 and ECC systems on-premises. The connector also enables integration with SAP's newer HANA-based SAP systems, such as S/4 HANA, whether they're hosted on-premises or in the cloud. The SAP connector supports message or data integration to and from SAP NetWeaver-based systems through Intermediate Document (IDoc), Business Application Programming Interface (BAPI), or Remote Function Call (RFC).
The SAP connector uses the SAP .NET Connector (NCo) library and provides these operations or actions:
- Send to SAP: Send IDoc over tRFC, call BAPI functions over RFC, or call RFC/tRFC in SAP systems.
- Receive from SAP: Receive IDoc over tRFC, call BAPI functions over tRFC, or call RFC/tRFC in SAP systems.
- Generate schemas: Generate schemas for the SAP artifacts for IDoc, BAPI, or RFC.
For these operations, the SAP connector supports basic authentication through usernames and passwords. The connector also supports Secure Network Communications (SNC). SNC can be used for SAP NetWeaver single sign-on (SSO) or for additional security capabilities provided by an external security product.
The SAP connector integrates with on-premises SAP systems through the on-premises data gateway. In send scenarios, for example, when a message is sent from a logic app to an SAP system, the data gateway acts as an RFC client and forwards the requests received from the logic app to SAP. Likewise, in receive scenarios, the data gateway acts as an RFC server that receives requests from SAP and forwards them to the logic app.
This article shows how to create example logic apps that integrate with SAP while covering the previously described integration scenarios. For logic apps that use the older SAP connectors, this article shows how to migrate your logic apps to the latest SAP connector.
Prerequisites
To follow along with this article, you need these items:
- An Azure subscription. If you don't have an Azure subscription yet, sign up for a free Azure account.
- The logic app from where you want to access your SAP system and a trigger that starts your logic app's workflow. If you're new to logic apps, see What is Azure Logic Apps? and Quickstart: Create your first logic app.
- Your SAP application server or SAP message server.
- Download and install the latest on-premises data gateway on any on-premises computer. Make sure you set up your gateway in the Azure portal before you continue. The gateway helps you securely access on-premises data and resources. For more information, see Install an on-premises data gateway for Azure Logic Apps.
- If you use SNC with SSO, make sure the gateway is running as a user that's mapped against the SAP user. To change the default account, select Change account, and enter the user credentials.
- If you enable SNC with an external security product, copy the SNC library or files on the same machine where the gateway is installed. Some examples of SNC products include sapseculib, Kerberos, and NTLM.
- Download and install the latest SAP client library, which is currently SAP Connector (NCo 3.0) for Microsoft .NET 3.0.22.0 compiled with .NET Framework 4.0 - Windows 64-bit (x64), on the same computer as the on-premises data gateway. Install this version or later for these reasons:
- Earlier SAP NCo versions might become deadlocked when more than one IDoc message is sent at the same time. This condition blocks all later messages that are sent to the SAP destination, which causes the messages to time out.
- The on-premises data gateway runs only on 64-bit systems. Otherwise, you get a 'bad image' error because the data gateway host service doesn't support 32-bit assemblies.
- Both the data gateway host service and the Microsoft SAP Adapter use .NET Framework 4.5. The SAP NCo for .NET Framework 4.0 works with processes that use .NET runtime 4.0 to 4.7.1. The SAP NCo for .NET Framework 2.0 works with processes that use .NET runtime 2.0 to 3.5, but no longer works with the latest on-premises data gateway.
- Message content you can send to your SAP server, such as a sample IDoc file, must be in XML format and include the namespace for the SAP action you want to use.
Migrate to current connector
- If you haven't done so already, update your on-premises data gateway so that you have the latest version. For more information, see Install an on-premises data gateway for Azure Logic Apps.
- In the logic app that uses the older SAP connector, delete the Send to SAP action.
- From the latest SAP connector, add the Send to SAP action. Before you can use this action, recreate the connection to your SAP system.
- When you're done, save your logic app.
Send to SAP
This example uses a logic app that you can trigger with an HTTP request. The logic app sends an IDoc to an SAP server and returns a response to the requestor that called the logic app.
Add an HTTP Request trigger
In Azure Logic Apps, every logic app must start with a trigger, which fires when a specific event happens or when a specific condition is met. Each time the trigger fires, the Logic Apps engine creates a logic app instance and starts running your app's workflow.
In this example, you create a logic app with an endpoint in Azure so that you can send HTTP POST requests to your logic app. When your logic app receives these HTTP requests, the trigger fires and runs the next step in your workflow.
- In the Azure portal, create a blank logic app, which opens the Logic App Designer.
- In the search box, enter 'http request' as your filter. From the Triggers list, select When a HTTP request is received.
- Now save your logic app so that you can generate an endpoint URL for your logic app. On the designer toolbar, select Save.The endpoint URL now appears in your trigger, for example:
Add an SAP action
In Azure Logic Apps, an action is a step in your workflow that follows a trigger or another action. If you haven't added a trigger to your logic app yet and want to follow this example, add the trigger described in this section.
- In the Logic App Designer, under the trigger, select New step.
- In the search box, enter 'sap' as your filter. From the Actions list, select Send message to SAP.Or instead of searching, choose the Enterprise tab, and select the SAP action.
- If you're prompted for connection details, create your SAP connection now. Otherwise, if your connection already exists, continue with the next step so that you can set up your SAP action.Create an on-premises SAP connectionProvide the connection information for your SAP server. For the Data Gateway property, select the data gateway you created in the Azure portal for your gateway installation. When you're finished, select Create. Logic Apps sets up and tests your connection to make sure that the connection works properly.
- If the Logon Type property is set to Application Server, these properties, which usually appear optional, are required:
- If the Logon Type property is set to Group, these properties, which usually appear optional, are required:
By default, strong typing is used to check for invalid values by performing XML validation against the schema. This behavior can help you detect issues earlier. The Safe Typing option is available for backward compatibility and only checks the string length. Learn more about the Safe Typing option. - Now find and select an action from your SAP server.
- In the SAP Action box, select the folder icon. From the file list, find and select the SAP message you want to use. To navigate the list, use the arrows.This example selects an IDoc with the Orders type.If you can't find the action you want, you can manually enter a path, for example:TipProvide the value for SAP Action through the expression editor.That way, you can use the same action for different message types.For more information about IDoc operations, see Message schemas for IDOC operations.
- Click inside the Input Message box so that the dynamic content list appears. From that list, under When a HTTP request is received, select the Body field.This step includes the body content from your HTTP Request trigger and sends that output to your SAP server.When you're finished, your SAP action looks like this example:
- Save your logic app. On the designer toolbar, select Save.
Add an HTTP response action
Now add a response action to your logic app's workflow and include the output from the SAP action. That way, your logic app returns the results from your SAP server to the original requestor.
- In the Logic App Designer, under the SAP action, select New step.
- In the search box, enter 'response' as your filter. From the Actions list, select Response.
- Click inside the Body box so that the dynamic content list appears. From that list, under Send message to SAP, select the Body field.
- Save your logic app.
Test your logic app
- If your logic app isn't already enabled, on your logic app menu, select Overview. On the toolbar, select Enable.
- On the designer toolbar, select Run. This step manually starts your logic app.
- Trigger your logic app by sending an HTTP POST request to the URL in your HTTP Request trigger.Include your message content with your request. To the send the request, you can use a tool such as Postman.For this article, the request sends an IDoc file, which must be in XML format and include the namespace for the SAP action you're using, for example:
- After you send your HTTP request, wait for the response from your logic app.NoteYour logic app might time out if all the stepsrequired for the response don't finish within therequest timeout limit.If this condition happens, requests might get blocked.To help you diagnose problems, learn how you cancheck and monitor your logic apps.
You've now created a logic app that can communicate with your SAP server. Now that you've set up an SAP connection for your logic app, you can explore other available SAP actions, such as BAPI and RFC.
Receive from SAP
This example uses a logic app that triggers when the app receives a message from an SAP system.
Add an SAP trigger
- In the Azure portal, create a blank logic app, which opens the Logic App Designer.
- In the search box, enter 'sap' as your filter. From the Triggers list, select When a message is received from SAP.Or, you can go to the Enterprise tab, and select the trigger:
- If you're prompted for connection details, create your SAP connection now. If your connection already exists, continue with the next step so you can set up your SAP action.Create an on-premises SAP connectionProvide the connection information for your SAP server. For the Data Gateway property, select the data gateway you created in the Azure portal for your gateway installation. When you're finished, select Create. Logic Apps sets up and tests your connection to make sure that the connection works properly.
- If the Logon Type property is set to Application Server, these properties, which usually appear optional, are required:
- If the Logon Type property is set to Group, these properties, which usually appear optional, are required:
By default, strong typing is used to check for invalid values by performing XML validation against the schema. This behavior can help you detect issues earlier. The Safe Typing option is available for backward compatibility and only checks the string length. Learn more about the Safe Typing option. - Provide the required parameters based on your SAP system configuration.You can optionally provide one or more SAP actions. This list of actions specifies the messages that the trigger receives from your SAP server through the data gateway. An empty list specifies that the trigger receives all messages. If the list has more than one message, the trigger receives only the messages specified in the list. Any other messages sent from your SAP server are rejected by the gateway.You can select an SAP action from the file picker:Or you can manually specify an action:Here's an example that shows how the action appears when you set up the trigger to receive more than one message.For more information about the SAP action, see Message schemas for IDOC operations
- Now save your logic app so you can start receiving messages from your SAP system.On the designer toolbar, select Save.
Your logic app is now ready to receive messages from your SAP system.
Note
The SAP trigger isn't a polling trigger but is a webhook-based trigger instead.The trigger is called from the gateway only when a message exists, so no polling is necessary.
Test your logic app
- To trigger your logic app, send a message from your SAP system.
- On the logic app menu, select Overview. Review the Runs history for any new runs for your logic app.
- Open the most recent run, which shows the message sent from your SAP system in the trigger outputs section.
Receive IDOC packets from SAP
You can set up SAP to send IDOCs in packets, which are batches or groups of IDOCs. To receive IDOC packets, the SAP connector, and specifically the trigger, doesn't need extra configuration. However, to process each item in an IDOC packet after the trigger receives the packet, some additional steps are required to split the packet into individual IDOCs.
Here's an example that shows how to extract individual IDOCs from a packet by using the
xpath()
function:- Before you start, you need a logic app with an SAP trigger. If you don't already have this logic app, follow the previous steps in this topic to set up a logic app with an SAP trigger.For example:
- Get the root namespace from the XML IDOC that your logic app receives from SAP. To extract this namespace from the XML document, add a step that creates a local string variable and stores that namespace by using an
xpath()
expression:xpath(xml(triggerBody()?['Content']), 'namespace-uri(/*)')
- To extract an individual IDOC, add a step that creates an array variable and stores the IDOC collection by using another
xpath()
expression:xpath(xml(triggerBody()?['Content']), '/*[local-name()='Receive']/*[local-name()='idocData']')
The array variable makes each IDOC available for your logic app to process individually by enumerating over the collection. In this example, the logic app transfers each IDOC to an SFTP server by using a loop:Each IDOC must include the root namespace, which is the reason why the file content is wrapped inside a<Receive></Receive
element along with the root namespace before sending the IDOC to the downstream app, or SFTP server in this case.
Tip
You can use the quickstart template for this pattern by selecting this template in the Logic App Designer when you create a new logic app.
Generate schemas for artifacts in SAP
This example uses a logic app that you can trigger with an HTTP request. The SAP action sends a request to an SAP system to generate the schemas for specified IDoc and BAPI. Schemas that return in the response are uploaded to an integration account by using the Azure Resource Manager connector.
Add an HTTP Request trigger
- In the Azure portal, create a blank logic app, which opens the Logic App Designer.
- In the search box, enter 'http request' as your filter. From the Triggers list, select When a HTTP request is received.
- Now save your logic app so you can generate an endpoint URL for your logic app.On the designer toolbar, select Save.The endpoint URL now appears in your trigger, for example:
Add an SAP action to generate schemas
- In the Logic App Designer, under the trigger, select New step.
- In the search box, enter 'sap' as your filter. From the Actions list, select Generate schemas.Or, you also can choose the Enterprise tab, and select the SAP action.
- If you're prompted for connection details, create your SAP connection now. If your connection already exists, continue with the next step so you can set up your SAP action.Create an on-premises SAP connection
- Provide the connection information for your SAP server. For the Data Gateway property, select the data gateway you created in the Azure portal for your gateway installation.
- If the Logon Type property is set to Application Server, these properties, which usually appear optional, are required:
- If the Logon Type property is set to Group, these properties, which usually appear optional, are required:
By default, strong typing is used to check for invalid values by performing XML validation against the schema. This behavior can help you detect issues earlier. The Safe Typing option is available for backward compatibility and only checks the string length. Learn more about the Safe Typing option. - When you're finished, select Create.Logic Apps sets up and tests your connection to make sure that the connection works properly.
- Provide the path to the artifact for which you want to generate the schema.You can select the SAP action from the file picker:Or, you can manually enter the action:To generate schemas for more than one artifact, provide the SAP action details for each artifact, for example:For more information about the SAP action, see Message schemas for IDOC operations.
- Save your logic app. On the designer toolbar, select Save.
Test your logic app
- On the designer toolbar, select Run to trigger a run for your logic app.
- Open the run, and check the outputs for the Generate schemas action.The outputs show the generated schemas for the specified list of messages.
Upload schemas to an integration account
Optionally, you can download or store the generated schemas in repositories, such as a blob, storage, or integration account. Integration accounts provide a first-class experience with other XML actions, so this example shows how to upload schemas to an integration account for the same logic app by using the Azure Resource Manager connector.
- In the Logic App Designer, under the trigger, select New step.
- In the search box, enter 'Resource Manager' as your filter. Select Create or update a resource.
- Enter the details for the action, including your Azure subscription, Azure resource group, and integration account. To add SAP tokens to the fields, click inside the boxes for those fields, and select from the dynamic content list that appears.
- Open the Add new parameter list, and select the Location and Properties fields.
- Provide details for these new fields as shown in this example.
The SAP Generate schemas action generates schemas as a collection, so the designer automatically adds a For each loop to the action. Here's an example that shows how this action appears:NoteThe schemas use base64-encoded format.To upload the schemas to an integration account,they must be decoded by using thebase64ToString()
function.Here's an example that shows the code for the'properties'
element: - Save your logic app. On the designer toolbar, select Save.
Test your logic app
- On the designer toolbar, select Run to manually trigger your logic app.
- After a successful run, go to the integration account, and check that the generated schemas exist.
Enable Secure Network Communications
Before you start, make sure that you met the previously listed prerequisites:
- The on-premises data gateway is installed on a machine that's in the same network as your SAP system.
- For SSO, the gateway is running as a user that's mapped to an SAP user.
- The SNC library that provides the additional security functions is installed on the same machine as the data gateway. Some examples include sapseculib, Kerberos, and NTLM.To enable SNC for your requests to or from the SAP system, select the Use SNC check box in the SAP connection and provide these properties:
Property Description SNC Library Path The SNC library name or path relative to NCo installation location or absolute path. Examples are sapsnc.dll
or.securitysapsnc.dll
orc:securitysapsnc.dll
.SNC SSO When you connect through SNC, the SNC identity is typically used for authenticating the caller. Another option is to override so that user and password information can be used for authenticating the caller, but the line is still encrypted. SNC My Name In most cases, this property can be omitted. The installed SNC solution usually knows its own SNC name. Only for solutions that support multiple identities, you might need to specify the identity to be used for this particular destination or server. SNC Partner Name The name for the back-end SNC. SNC Quality of Protection The quality of service to be used for SNC communication of this particular destination or server. The default value is defined by the back-end system. The maximum value is defined by the security product used for SNC. NoteDon't set the environment variables SNC_LIB and SNC_LIB_64 on the machine where you have the data gateway and the SNC library. If set, they take precedence over the SNC library value passed through the connector.
Safe typing
By default, when you create your SAP connection, strong typing is used to check for invalid values by performing XML validation against the schema. This behavior can help you detect issues earlier. The Safe Typing option is available for backward compatibility and only checks the string length. If you choose Safe Typing, the DATS type and TIMS type in SAP are treated as strings rather than as their XML equivalents,
xs:date
and xs:time
, where xmlns:xs='http://www.w3.org/2001/XMLSchema'
. Safe typing affects the behavior for all schema generation, the send message for both the 'been sent' payload and the 'been received' response, and the trigger.When strong typing is used (Safe Typing isn't enabled), the schema maps the DATS and TIMS types to more straightforward XML types:
When you send messages using strong typing, the DATS and TIMS response complies to the matching XML type format:
When Safe Typing is enabled, the schema maps the DATS and TIMS types to XML string fields with length restrictions only, for example:
When messages are sent with Safe Typing enabled, the DATS and TIMS response looks like this example:
Advanced scenarios
Confirm transaction explicitly
When you send transactions to SAP from Logic Apps, this exchange happens in two steps as described in the SAP document, Transactional RFC Server Programs. By default, the Send to SAP action handles both the steps for the function transfer and for the transaction confirmation in a single call. The SAP connector gives you the option to decouple these steps. You can send an IDOC and rather than automatically confirm the transaction, you can use the explicit Confirm transaction ID action.
This capability to decouple the transaction ID confirmation is useful when you don't want to duplicate transactions in SAP, for example, in scenarios where failures might happen due to causes such as network issues. By confirming the transaction ID separately, the transaction is only completed one time in your SAP system.
Here is an example that shows this pattern:
- Create a blank logic app and add an HTTP trigger.
- From the SAP connector, add the Send IDOC action. Provide the details for the IDOC that you send to your SAP system.
- To explicitly confirm the transaction ID in a separate step, in the Confirm TID property, select No. For the optional Transaction ID GUID property, you can either manually specify the value or have the connector automatically generate and return this GUID in the response from the Send IDOC action.
- To explicitly confirm the transaction ID, add the Confirm transaction ID action. Click inside the Transaction ID box so that the dynamic content list appears. From that list, select the Transaction ID value that's returned from the Send IDOC action.After this step runs, the current transaction is marked complete at both ends, on the SAP connector side and on SAP system side.
Known issues and limitations
Here are the currently known issues and limitations for the SAP connector:
- The SAP trigger doesn't support data gateway clusters. In some failover cases, the data gateway node that communicates with the SAP system might differ from the active node, which results in unexpected behavior. For send scenarios, data gateway clusters are supported.
- The SAP connector currently doesn't support SAP router strings. The on-premises data gateway must exist on the same LAN as the SAP system you want to connect.
Connector reference
For technical details about triggers, actions, and limits, which are described by the connector's OpenAPI (formerly Swagger) description, review the connector's reference page.
Next steps
- Connect to on-premises systems from Azure Logic Apps.
- Learn how to validate, transform, and use other message operations with the Enterprise Integration Pack.
- Learn about other Logic Apps connectors.