Category Archives: Architecture

Configuring an HTTP Content Server for Documents in the Business Workplace

Posted on by

A class must be created for documents so that they can be stored by the Knowledge Provider. The class SOFFPHIO is assigned to the documents in the Business Workplace in the Knowledge Provider. Storage categories are assigned to this class with content repositories. The content repositories contain the link data for the current storage system, that is, the SAP database or the HTTP Content Server.

loio4e39d88cc0aa382de10000000a42189c_LowRes

The storage category SOFFDB is assigned by default to the class SOFFPHIO, meaning that the documents are stored in the SAP database. If you connect an external HTTP Content Server to the Knowledge Provider, you have to make settings so that documents in the Business Workplace can be stored on the external server.

Capture

After you have made the settings, PC documents and binary documents that have been created in the Business Workplace are stored on the configured content server. The documents that were stored in the Business Workplace before this time remain on the SAP database. (Therefore the connection to this, the storage category SOFFDB, cannot be changed or deleted.)

ABAP (ASCS) high availability setup

Posted on by

This ABAP (ASCS) high availability setup is used for ABAP only SAP solutions.

Figure 1. ABAP (ASCS) high availability setup

ha_sap2

ABAP (ASCS) high availability setup
The ASCS high availability setup consists of at least two SCS nodes which run the ASCS and ERS instances. Under regular conditions the ERS will always be started on the node where the ASCS is not running. This failover setup has no downtime due to fast failure detection and in-memory data exchange between ES and ERS in case the ASCS must be moved to the failover node. During the failover, the virtual IP address for the ASCS is moved to the failover node too, so its addressing remains unchanged.

Primary and Additional AS node
The Primary AS node and the Additional AS nodes consist of ABAP Application Servers which will be restarted in place in case of software failures. Protection against hardware outages is done by setting up multiple Application Servers on different hardware. Therefore the System Automation for Multiplatforms concept for SAP high availability does not consider failovers of Application Servers to other nodes because Application Server restarts take a lot of time. Other Application Servers must be sized to take the additional workload from failing servers.

Web Dispatcher and SAProuter node (optional)
The Web Dispatcher and SAP router high availability setups consists of at least two nodes which run the instances in a failover setup. The components are key for the clients to access the Application Servers, so in case of a failure the instance failover to standby nodes includes their virtual IP addresses too.

Database high availability setup
The database high availability setup is explained in Database high availability installation setup.

NFS high availability setup
The NFS high availability setup is explained in NFS high-availability installation setup.
Setup a ASCS SAP high availability solution with the following components.
Table 1. ABAP resources and the corresponding components
ABAP Resources SAP component
ABAP resources
  • ABAP SAP Central Services (ASCS) instances using an own virtual host name on two nodes.
  • Enqueue Replication Server using an own virtual host name on two nodes.
  • Database Server instances using an own virtual host name on two nodes.
  • Primary Application Server for ABAP instance on first node.
  • Additional Application Server for ABAP instances on other nodes.
ABAP independent resources (optional)
  • Host Agent
  • Web Dispatcher instances using an own virtual host name on two nodes.
  • SAProuter setup on two nodes.
source:https://www.ibm.com/support/knowledgecenter/en/SSRM2X_4.1.0/com.ibm.samp.doc_4.1/sampicascs_setup.html

RFC Cycle

Posted on by

Execution flow

RFC cycle page

Examples:
For example, the following illustration showing an ECC system communicating with other systems (another ECC, BW, SCM, CRM) through Remote Function Calls

RFC in ECC

RFC Cycle

Measured times of a synchronous RFC from the perspective of performance analyzing

RFC Cycle

The figure illustrates the course and measured times of a synchronous RFC, which are displayed in the single-record statistics (Transaction STAD) and in the workload monitor (Transaction ST03).RFC Cycle shown as follow:

  1. Establishing the connection (the CMINIT phase)
  2. Data exchange (CMSEND and CMRECEIVE phases)
  3. Closing the connection or wait status
  4. Repeated data exchange
  5. Closing the connection

In this procedure, Establishing the connection should take only a few milliseconds. If you find this status (the CMINIT phase) often in the work process overview, there may be an overload in the recipient system.

  • 2317074 – “timeout during allocate” when starting external programs
  • 1842162 – Connection test SM59: Timeout during allocate
  • 581509 – Reasons for “timeout during allocate”
  • 944792 – Runtime analysis when you start external RFC servers
  • 1333483 – Timeout during allocate of a registered program

During the connection,RFC users are running in the Dialog work process in the receiver system. By specifying RFC user ID, you can monitor the RFC process in the receiver system.

  • 2180934 – Analysis of Work process in “On Hold” RFC, or Stopped CPIC status
  • 1260137 – Work process status “Stopped RFC” by SAPLARFC (tRFC/qRFC)
  • 1324454 – qRFC scheduler is still set to WAITING status

After the data exchanging, finally, the connection is closed. The recipient work process is free again, and the sender work process continues with its work.

  • 1520551 – RFC: Connections in Gateway are not closed

 

Source:https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=471174773

Enterprise Search Architecture

ESR

Enterprise Services Repository is “the central repository, which is part of the SAP NetWeaver platform, where enterprise services, business objects, and business processes and their metadata is stored

Enterprise Services Repository is the central information repository about enterprise services in SAP’s enterprise SOA ecosystem. In technical terms, it is a meta data repository, meaning that it stores data that describes other data. The meta data inside the repository is then used by development tools, modeling tools, operational management tools, and by other services to help them do their jobs. The repository has also been given the job of storing descriptions of business objects and models that show how services work together in process components

ESR