Security, Logging, Updates, Customizing

Transcription

1 Archive Content Connector ACC Admin Documentation: Security, Logging, Updates, Customizing Author: Date: May 2018 Jochen Hager, SolutionXchg Version: Version:

2 1. Table of Contents Author and Copyright: Jochen Hager, solutionxchg; Version: May 2018 Table of Contents: 1. Table of Contents ACC Function and Purpose General Common Use Cases Exclusions and Limitations in the current Version Operating System and Environment Installation Preparation... 5 Selecting an Operating System Installation for Windows Operating Systems... 6 Java Installation... 6 Tomcat Installation Installation for Unix/Linux Operating Systems... 8 Java Installation... 9 Tomcat Installation ACC Installation Preparation ACC Installation Installation Testing Installation Variations (changing servlet and service name / multiple instances) ACC Administration and Configuration General License Key Information General Configuration Parameters Connected Archive Configuration ACC Special Commands and Common Tests ACCTest Parameter ACCTest&serverInfo ACCTest&info ACCTest&get ACCTest&get&docId=<filename.pdf> ACCTest&create&docId=<filename.pdf> ACCReset Locking the ACC to one specific connected remote Repository Setting a one-call lock Setting a permanent lock Releasing a permanent lock SAP Configuration General Changing an existing OAC0 Configuration Version:

3 3. Adding an additional Repository to the Configuration Adding a new repository in the ACC Configuration Configuring SAP for HTTPS SSL Configuration Running Tomcat on HTTPS (SSL on incoming requests) Creating a Self-Signed CA and a derivitive Certificate Setting up your certificates Adding certificates to a Tomcat accessible keystore Testing your configuration Calling Remote ContentServers with HTTPS (SSL on outgoing requests) Logging and Log Settings General ACC and related Log Settings Tomcat Logging Structure ACC Logging Structure Centralized ACC Logging Configuration Webapps Specific Logging Debugging Techniques and Status Checks Unix Status Checks Tomcat System Logging and Status Checks Test Calls using curl Testing using standard SAP Test Transactions Summary Version:

4 2. ACC Function and Purpose 1. General The Archive Content Connector (ACC) is an HTTP Servlet that connects one SAP system to several SAP ArchiveLink content repositories. Using the ACC allows a system administrator to connect a quality control content repository (read/write mode) and a production content repository (read only mode) to the same configuration in SAP. With that, an end user retrieving a document from your SAP QA system (typically a full copy of production) will have the ability to retrieve all production documents read-only as if he or she were using PROD, while have the capability to store and retrieve QA-only documents seamlessly from a separate content repository. The ACC redirects the calls appropriately to make this magic happen flawlessly in the background. Based on its configuration, it will for example, first attempt to retrieve a given document from the connect PROD content repository, and if not found, continue to attempt retrieval of that document from a second or third QA content repository. Similar techniques allow directing write traffic to the correct location defined in ACC customizing. With the ACC by solutionxchg the time-consuming effort to prime your QA repository with data or to manipulate SAP tables after each creation of a quality control SAP clone is completely eliminated. Your test cases continue to function exactly the same in QA and Prod. Regression testing for archive document related business scenarios and workflows has never been easier. Finally, a refresh of your QA system is not disabling your document access for testing anymore. At the same time your production system can be protected against accidental or un-intended writes by setting the ACC Prod repository connection to read-only, while allowing full read/write access on the ACC QA repository connection. 2. Common Use Cases During active migration a proxy server is called to serve up legacy documents. Settings are maintained for every repository, pointing to an unsecured access point of the legacy KGS archive for serving up documents not yet migrated into the new production archive (HTTP Source Parameters) and to the new production KGS Archive (HTTP Destination Parameters). 3. Exclusions and Limitations in the current Version It is possible to point to an unsecured archive. This was done during the switch-over period in which the Proxy service is active in production also. As a result, SAP SecKey checks were not enforced for documents not yet migrated. Documents accessed from the Destination Production Archive are secured through SAP SecKeys and the keys are validated. Version:

5 3. Operating System and Environment Installation 1. Preparation Selecting an Operating System The ACC is programmed in Java as a Apache Tomcat servlet. It will function identical on Windows or on Unix. In addition to the operating system, the ACC requires the installation of the JRE from Oracle or OpenJava and the installation of the latest supported release of Apache Tomcat. While the ACC can be hosted within an existing Tomcat deployment, for ease of administration and non-interference with other enterprise software, we recommend to setup a light-weight, separate, virtual Unix or Linux environment without desktop installation and with minimal system specifications. A graphical user interface is not required for the operation of the ACC. Windows Operating Systems System requirements: Typically a virutal environment is chosen Windows 10 Professional or Windows Server 2016 (Windows 2012 R2 on request) 2.5 GHz 64-bit processor (recommended is a multicore Xeon processor) 2 GB of memory minimum for Windows with Desktop Experience 64 GB harddisk for Windows operating system and paging requirements 10 MB for ACC requirements (can be part of the 8 GB for logging) 8 GB for logging Linux Operating Systems System requirements: Typically a virutal environment is chosen Various Linux variations are supported: Unix/Linux o Debian 9.x o Suse 12.x o RedHat 9.x o Ubuntu 17.x o Mac OSX High Sierra 400 MHz Pentium 64-bit processor (single or multicore) or better 1 GB of memory minimum for Linux without desktop installation 10 MB for ACC requirements (can be part of the 8 GB for logging) 8 GB for logging 1 GB for ACC requirements (can be part of the 64 GB) Java Run-Time-Engine (JRE) At the time of the creation of this document, the most current Java version was JRE 8 Update 151. Please install the latest release under general availability. Please choose the 64-bit version of JRE. Version:

6 The ACC was tested in lab evironments with Oracle Java for Windows and OpenJDK for Linux systems as well as Oracle Java for OSX. Please choose the 64-bit version of Tomcat. Tomcat core is sufficient. Apache Tomcat At the time of the creation of this document, the most current and recommended Apache Tomcat version was Installation for Windows Operating Systems Java Installation Please download the most current Java RE for your Windows operating system. Please choose the 64- bit version. The download instruction can be found at: (October 2017). Tomcat Installation Please install the 64-bit Windows Tomcat version for your Windows operating. It can be found at (October 2017). Version:

7 Create a directory c:/program Files/Tomcat and unzip the content in this directory. Next download and start the Windows Service Installer. Select java path to match your Java installation: Select Tomcat Installation path: Version:

8 Then click Install and Run Apache Tomcat on the next screen. The installer will install a quick start icon in your windows task bar. For convenience, drag the Tomcat8w program in Tomcat/bin into your task bar and pin it to the task bar. 3. Installation for Unix/Linux Operating Systems The ACC is best installed on a headless Linux system (headless, meaning w/o graphical user interface). Several test installation have been done on various Linux platforms: RedHat Linux, Apple OSX, Suse, Debian and Ubuntu Linux. The following is a quick overview on how to set up a Debian system in a VM Ware environment. Download the latest stable Debian image for your CPU or VM Ware environment. For installation paramters choose: Bridged Networking 1 Core / 512 MB Memory (minimal configuration) Version:

9 Choose Graphic Installation: Follow the prompts, selecting installation language, location, keyboard language, and a hostname and domain for your system (example: accdeb9hlt1/local). Choose your root password and a local non-administrative full user name, account name, password, time zone. In a VM environment choose Guided entire disk when asked about disk partitioning and select All files in one partition. Accept the partitioning and write it to disk. On the confirmation screen, select Yes. At this time there are no other installation CDs or ISO images, so select No. Make your selection for the package manager, download site and proxy. Make your selection regarding survey data. Important: for headless server install, deselect Debian desktop environment", (no web server), deselect print server, select SSH, select Standard system utilities. Install the GRUB boot loader. Select Yes. Select /dev/sda/ or the appropriate boot drive. Reboot the server and log in as root. Use command: apt-get install libnss-mdns to install the Avahi DNS demon to make your system discoverable in the network. This completes the OS specific installation instructions. Java Installation The ACC is tested and released for the use with Oracle Java as well as OpenJDK. For OpenJDK installation use the following commands: # assume administrative privileges su root # install JRE using the Debian package installer apt-get install openjdk-8-jre # find out the location of your OpenJDK install which java Tomcat Installation The following commands for Debain can be used to install Tomcat: # check version unless you want older version specifically! apt-get upgrade Version:

10 # install the unzip and wget utilities apt-get install unzip wget # get core tomcat only, no additional documentation, no source code wget -P /opt useradd -r tomcat --shell /bin/false # review your download cd /opt This command sequence check for upgrades first, then installs the unzip and wget tools and then uses wget to download Tomcat for the Tomcat online repository. Finally a user tomcat without shell privileges is created. The tar archive is located in /opt # unpack the download tar -zxf /opt/apache-tomcat tar.gz # sym-link to logical path ln -s /opt/apache-tomcat /opt/tomcat-latest # create system user tomcat:tomcat useradd -r tomcat --shell /bin/false # change ownership to system user tomcat chown -hr tomcat: /opt/tomcat-latest /opt/apache-tomcat- To allow for system command startup and stop of Tomcat services create the following file in an editor (nano, vi): nano /etc/systemd/system/tomcat.service Enter into file: Begin [Unit] Description=Tomcat8 After=network.target [Service] Type=forking User=tomcat Group=tomcat Environment=CATALINA_PID=/opt/tomcat-latest/tomcat8.pid Environment=TOMCAT_JAVA_HOME=/usr/bin/java Environment=CATALINA_HOME=/opt/tomcat-latest Environment=CATALINA_BASE=/opt/tomcat-latest Environment=CATALINA_OPTS= Environment="JAVA_OPTS=-Dfile.encoding=UTF-8 -Dnet.sf.ehcache.skipUpdateCheck=true - XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:MaxPermSize=128m -Xms512m - Xmx512m" ExecStart=/opt/tomcat-latest/bin/startup.sh ExecStop=/bin/kill -15 $MAINPID [Install] WantedBy=multi-user.target End # Activate new settings: systemctl daemon-reload systemctl restart tomcat systemctl enable tomcat # Edit file: nano conf/tomcat_users.xml <role rolename="manager-gui"/> <user username="<admin user>" password="<admin password>" roles="manager-gui"/> # example: accadmin / secretpassword Version:

11 # Edit file: nano webapps/manager/meta-inf/context.xml #change 127 to 192 for local network allowed access or change to match your company network IP # IP Address: ip addr show Restart Tomcat after all changes are complete: Systemctl stop tomcat Systemctl start tomcat Test you Tomcat installation using the following URL: Log into the tomcat manager by clicking on Manager App and using the credentials established above: This concludes the installation of Tomcat for ACC purposes on Debian Linux. Please request other installation procedures for your flavor of Linux systems from info@solutionxchg.com. Version:

12 4. ACC Installation Preparation 1. Download the latest release version of the ACC from 2. Rename the war file by striking the operating system specific ending from the filename. 3. Copy the war file onto the target machine: a) Windows: Use Windows copy mechanismns to transfer the war file onto the target machine. b) Unix: scp solxchgserver.war Further ACC installation instructions for Windows and Unix are identical. ACC Installation 1. Download the ACC war file from the solutionxchg website: 2. Copy the ACC war file into your Tomcat/webapps folder: solxchgserver.war -> Tomcat/webapps/solXchgServer.war a. In case of an update: If there already exists an older solxchgserver.war in the target location, then overwrite it. b. In case of an update: If there already exists a webapps install directory for solxchgserver, then stop Tomcat, preserve and custom configuration files (e.g. a webapps specific logging.properties file, or a custom web.xml file), delete the directory tree for solxchgserver to start with a clean install. 3. Restart Tomcat 4. Tomcat autodeploy will unpack the file and install (if autodeploy is turned off in your enviroment, please consult your administrator for the approved deployment technique in your organisation). 5. Review the configuration files in Tomcat/webapps/solXchgServer/WEB-INF/resources: a. ACConnector.properties ACC configuration file b. Tomcat.logging.properties Modified standard tomcat.logging file c. Tomcat-users.xml Modified tomcat-users.xml file d. Tomcat.addto.catalina.properties Add-to values for catalina.properties file e. Webapps.logging.properties Custom webapps.logging file for ACC 6. Place the ACConnector.properties file in Tomcat/conf and adjust: Tomcat/webapps/solXchgServer/WEB-INF/resources/ACConnector.properties -> Tomcat/conf Version:

13 7. In standard tomcat configuration file catalina.properties, extend the shared.loader entry to include the Tomcat conf directory: shared.loader="${catalina.base}/conf". Use the ACC sample in Tomcat/webapps/tomcat.addto.catalina.properties for reference. 8. Open the Tomcat/conf/logging.properties file with the ACC template in Tomcat/webapps/tomcat.logging.properties in an editor of your choice (Windows: Notepad++ with compare plugin, Unix: diff) and compare/adjust the filetomcat/conf/logging.properties directory. You can also copy and replace: Tomcat/webapps/solXchgServer/WEB- INF/resources /tomcat.logging.properties -> filetomcat/conf/logging.properties 9. Proceed to do the same with the Tomcat/conf/tomcat-users.xml file and the Tomcat/webapps/solXchgServer/WEB-INF/resource/tomcat-users.xml. The admin account values can also be adjusted through the tomcat8w configuration app on Windows. 10. The file Webapps.logging.properties allows for a modified logging technique, minimizing the changes in the general tomcat logging.properties file. See additional information in the administration section under logging. Installation Testing Perform these steps for simple installation testing: 1. Start Tomcat manager with and logging into Tomcat manager by clicking on the Manager App button. Use the user and password you chose during Tomcat installation. This confirms that Tomcat is functional at it basic level and you have a valid manager user. 2. In the manager app view, you should see an entry like this: Version:

14 3. Click on the solxchgserver app link to display a complete test and resource webpage for easy self testing and documentation access: 4. Enter a self test URL in a new browser windows or tab (ACCTest mode, serverinfo): If all is fine, this command will display the configuration file. Version:

15 An even simpler response test is available (ACCTest mode, info): 5. Test access to Tomcat from another desktop computer in your network to test firewall settings on your machine and hostname resolution to IP address in your name directory for the ACC server. For standard Tomcat installations, open the firewall for TCP on ports 8005, 8080, 8009, 8334 and (to enable simple connectivty test) also allow ping requests to the server. a. Test: > ping servername or > ping ip-address b. Test: or from a browser Further information on how to configure the Windows Firewall for specific ports: Further information on how to configure the Windows Firewall for pings: 6. Test PDF document display in your browser and retrieve this manual from your install as PDF: 7. Further test calls exists, including storing a document locally, using the Postman application in Google Chrome with any local PDF using a self-defined filename as docid and retrieving the same document using a ACCTest&get with that docid to retrieve the document. Installation Variations (changing servlet and service name / multiple instances) The ACC can be started several times within the same Tomcat. This is done by installing another serverlet within the same Tomcat under webapps (by using the same WAR, but with a different name, e.g. solxchgserver2.war) and then changing the web.xml file under ${catalina.base}/webapps/solxchgserver2/web-inf from: Version:

16 to this: <servlet-name>serverinfoservlet</servlet-name> <url-pattern>/acconnector</url-pattern> <servlet-name>serverinfoservlet</servlet-name> <url-pattern>/acconnector2</url-pattern> Also duplicate the ACC configuration file und ${catalina.base}/webapps/solxchgserver/web-inf and save it as ACConnector2.properties, resembling the URL pattern string in the web.xml. The ACC checks its service name and looks for a configuration file name of <service name>.properties in the conf directory. The service name change in web.xml is necessary to start the service with a different configuration file. The second instance is addressed by URLs constructed like this: Its configuration file is expected to in the conf directory, named ACConnector2.properties. Version:

17 5. ACC Administration and Configuration 1. General The ACC configuration file ACConnector.properties is expected in the Tomcat/conf directory. This is accomplished by adjusting the configuration file catalina.properties, extending the shared.loader entry to include the Tomcat conf directory: shared.loader="${catalina.base}/conf (see section installation instructions). The configuration file defines parameters valid for general operation of the servlet as well as a set of parameters describing the access to all connected archive. The configuration file syntax allows for a variable number of connected archive. The file is read once at startup of the ACC and is only read again when an ACCReset special command is received. The reset forces the ACC to read its configuration again with the next command it receives. Changes in logging configuration requires a Tomcat restart. 2. License Key Information The product auto-installs with a 30-day evaluation licenses. A full usage license can be obtained by sending a license request to info@solutionxchg.com. SolutionXchg offers enterprise wide licenses with annual maintenance fee or single computer licenses without annual maintenance fee. Licensing is perpetual for a specific version. If you would like to update or upgrade your single computer license simple re-purchase the software with an existing customer upgrade discount. Purchases can be made by CreditCard/PurchaseCard only. SolutionXchg will send you a Square.com invoice with purchase instruction. Upon receipt of funds, SolutionXchg transmits a valid license key. Your purchase is guaranteed by your credit card and Square.com. Please be advised that after the 30-day evaluation license has expired, the product will continue working in a test mode only. It will not perform any remote document retrieval or archival task any more. 3. General Configuration Parameters The following excerpt lists all general configuration parameters: Parameter Name Example Comment remoteconnectiontimeout =2000 Value in ms; if missing or emtpy, Tomcat default values are used. remotereadtimeout =2000 Value in ms; if missing or emtpy, Tomcat default values are used. trace =false If set to true, a trace file of the transmitted data streams (request and response) on put/post commands to a remote archive will be written to the logs directory. The value should be set to trace=false in a production environment. Allowed values: true/false. licensekey =01ERP9QB5N =01-ER-P9-QB-5N =<empty> A valid licensekey is 10 characters long, without dashes. Entering an invalid key or GETSYSID as a key, prompt the ACC to write its systemid into the log file. Please submit the systemid to SolutionXchg to obtain a valid license key. Leaving the key field empty triggers the 30 day evaluation period. Version:

18 allowedarchiveids =T1,T2,A1 = =<empty> <missing> List of allowed archiveids (repository names in OAC0). Comma separated, NO BLANKS PLEASE. The symbol (asterix) allows all archiveid values. If <empty>, no archiveids are alllowed. If missing, all archiveids are blocked. / SolutionXchg Archive Content Connector Copyright by Jochen Hager, 2017 / / Timeout to remote archive server - same value for all calls in ms Suggested Values: remoteconnectiontimeout=2000 remotereadtimeout=2000 Default Values: none - Tomcat Defaults are used if missing or empty / remoteconnectiontimeout=2000 remotereadtimeout=2000 / Trace settings Suggested Values: If set to true, a trace file of the transmitted data stream will be written to the logs directory trace=false (allowed values: true/false) Default Values: false - no trace file is written / trace=false / License key settings Version:

19 Suggested Values: licensekey=<request valid license key from SolutionXchg - info@solutionxchg.com> Example, using a compact license key: licensekey=erp9qb5n Example, using an expanded license key: licensekey=er-p9-qb-5n To trigger SystemID display in logging us an invalid key, 8 or 9 characters long: Example: licensekey=getsysid Default Values (triggers no warning in log file): licensekey=<empty> (no license key set - triggers automatic 30 days trial period) / licensekey=getsysid / AllowedArchiveIds: list ArchiveIds in comma separated list or use >< as first list element Suggested Values: allowedarchiveids =<comma separated list of SAP repository ids (two letters or numbers); NO BLANKS> Example 1: allowedarchiveids=t1,a1 (Repositories >T1< and >A1< are allowed; DO NOT USE blanks in list) Example 3: allowedarchiveids=<empty> (no list specified or missing parameter: all repositories are blocked) Example 2: allowedarchiveids= (all repositories are allowed) Default Values: <missing parameter> (all archives are blocked) / allowedarchiveids=t1,t2,a1 // 4. Connected Archive Configuration The section describes the configuration of the attached archives. When the ACC receives a call, it relays the call to the first remote archive described by the first set of configuration parameters. If this remote archive response with a 200 for a get (GET) call or a 201 for a create (PUT or POST) call, it returns the result to the caller. If it receives anything but a 200 or 201, it attempts to relay the call to the next remote archive in the list. This process is repeated until one remote archive responds with 200 or 201 or the list of remote archives is exhausted, in which case a 400, 404, 405 or 500 error is returned. A syntax specifying the type of paramter followed by a dot and a number is used to group paramters into sections for each remote archive. Version:

20 Parameter Name Example Comment ipaddres.<i> ipaddress.1= Use IP address or DNS name. Cannot be emtpy. secureconnection.<i> secureconnection=true Values can be TRUE or FALSE. A different value or missing parameter defaults to FALSE. servicename.<i> servicename.1=/contentserver/content Server.dll Service name, beginning with a /, but not ending with /. Cannot be empty. serviceport.<i> serviceport.1=1090 HTTP or HTTPS port number for remote archive web service. Cannot be empty. serviceaccess.<i> serviceaccess.1=read,write,delete Comma separated list fo >read<, >write< and >delete< settings, NO BLANKS PLEASE, sequence is not significant. servicemode.<i> servicemode.1=substitutedoc A missing Paramter, an emtpy value, or a value not equal to >substitutedoc< trigger standard behavior. A value of >substitutedoc< triggers a the display of a placeholder document instead of the actual orginal document. / Server Listing for Archive Content Server Suggested Values for SAP ContentServer: ipaddress.<i>=<ip Address or hostname or DNS Address> secureconnection.<i>=<true/false, if missing, default is false; if true, HTTPS(SSL) is used> servicename.<i>=<service name, beginning with a "/" but no ending "/"> serviceport.<i>=<port number> serviceaccess.<i>=<comma separated list of >read< and >write< settings: e.g. >read<, >write<, >read,write<, >write,read<, >delete,write,read< Example: ipaddress.1= Example: secureconnection.1=true Example: servicename.1=/contentserver/contentserver.dll Example: serviceport.1=1090 Example: serviceaccess.1=read,write,delete Example: servicemode.1=substitutedoc First attempt against: / ipaddress.1= secureconnection.1=true servicename.1=/archive serviceport.1=8443 serviceaccess.1=read servicemode.1=standard Version:

21 / Second attempt against: / ipaddress.2= secureconnection.1=false servicename.2=/contentserver/contentserver.dll serviceport.2=1090 serviceaccess.2=read,write,delete servicemode.2=substitutedoc / Third attempt against: / ipaddress.3= servicename.3=/contentserver/contentserver.dll serviceport.3=1090 serviceaccess.3=read / Additional attempts with consecutive numbers after parameter name can be added. A skipped number breaks the sequence. EOF / This configuration example shows three remote servers. The serviceaccess parameter in each configuration can be used to protect or restrict access to a remote server for read access, write access or delete access. If the ACC receives a read command (get, serverinfo, info and other commands) it checks if a read is allowed for that remote server, if not, that remote server is skipped in the squence. If it receives a write command (create, update and other commands), it checks if a write is allowed for that remote server and, if not, that remote server is skipped in the squence. If it receives a delete command (delete command), it checks if a write is allowed for that remote server and, if not, that remote server is skipped in the squence. This mechanism allows the administrator to protect certain remote archives against accidential writes or deletes. This can be useful, if the ACC is used be a QA SAP system and the first connected remote archvie is the production archive. Allowing on read commands to this archive guarantees that no documents can be written from QA into the production archive. It further automatically redirects write calls to the first remote archive that allows write calls and successfully handles the call. Version:

22 6. ACC Special Commands and Common Tests The ACC call syntax allows for additonal URL commands parameters to test the installation, perform display of status and configration information. 1. ACCTest Parameter Adding the parameter ACCTest to a standard ArchiveLink URL call puts the ACC into test mode. ACCTest&serverInfo A test URL is contructed like this: It will call the ACC on the local machine at port 8080, sending it a serverinfo in Testmode. The response will be a listing the the ACCs configuration file as text output in your browser window. ACCTest&info A test URL contructed like this: It will call the ACC on the local machine at port 8080, sending it a info in Testmode. The response will be a alive repsonse as text output in your browser window, includig the version of the currently responding ACC. ACCTest&get A test URL is contructed like this: It will call the ACC on the local machine at port 8080, sending it a get in Testmode. The response will be the ACC Administration and Configuration manual, displayed as PDF in your browser window. The file is pulled from the local files system in the version that is part of the current installation. ACCTest&get&docId=<filename.pdf> A test URL is contructed like this: It will call the ACC on the local machine at port 8080, sending it a get in Testmode. The response will be the file, named filename.pdf, displayed as PDF in your browser window. The file is pulled from the local files system in the version that is part of the current installation. The file is located in under Tomcat webapps/solxchgserver/tmp. ACCTest&create&docId=<filename.pdf> A test URL contructed like this: will call the ACC on the local machine at port 8080, sending it a get in Testmode. The effect will be that the pay load of the create call, assumed to be a document, will be stored locally, using the file name supplied as docid paramter. The file is stored on the local files system as transmitted in the call. The file can be found under Tomcat webapps/solxchgserver/tmp. 2. ACCReset Using the Command ACCRest in the command section of a URL will force the ACC to re-read ist configuration file. The reset call is programmed to reset internal paramters and reinitialize the connector. Upon the next service call, the connector will re-read its configuration from the filesystem and process all paramters as if the connector had been restarted through a Tomcat restart. Version:

23 A reset URL is constructed like this: This does not reset logging configuration. To reset or change logging parameters a restart of Tomcat is necessary. The ACC uses basic Java and Tomcat logging which is deeply embedded into Tomcat and therefore requires a server restart. 3. Locking the ACC to one specific connected remote Repository Setting a one-call lock The ACC can be forced to probe only one specific repository, not looping through all the connected remote repositories. Using the parameter remoteserver=<i> forces the ACC to only attempt to connect to the remote server with the number <i> in the configuration file s configuration sequence. A restricted ACC URL is constructed like this: WARNING: The remoteserver parameter is passed on to the remote archive. Compatibiliity has to confirmed through testing with the connected remote archives. This parameter might not be compatible with all encountered remote archive brands. Setting a permanent lock The ACC can be instructed to lock onto a specific remote server. The special control command to set a lock (example for remote server 3) is: Until released or restarted, the ACC will lock onto just the one remote server that was specified in the lock command. Releasing a permanent lock The ACC can be instructed to release a lock to a specific remote server. The special control command to release the lock is: Once the lock is released, the ACC will resume trying the configured remote servers, one at a time, in the configured sequence. Version:

24 7. SAP Configuration 1. General The ACC is configured exactly like a regular SAP ArchiveLink connected archive in SAP. The ACC is identified by the following set of parameters: HTTP Server <DNS name or IP address, e.g > Port Number <Port Number Tomcat is listening to, e.g. 8080> HTTP Script <ACC service name (case sensitive): /solxchgserver/acconnector Clicking the scale symbol in the configuration screen to determine connectivity allows to verify if at least one connected remote archive is responding. If all are non-repsonsive the SAP System will display the error message returned by the last remote archive in sequence or a general error, if the ACC is not reachable. 2. Changing an existing OAC0 Configuration To connect an ACC to your SAP configuration, one would modify an existing connection like: Version:

25 to this: replacing the HTTP server name or address with the ACC <hostname> or <IP address>, change the port number to 8080 (ACC Tomcat port number) and change the HTTP script name to /solxchgserver/acconnector. 3. Adding an additional Repository to the Configuration The additional repository is added to the SAP configuration as always. A new entry in OAC0 is created and all fields are filled accordingly. All other customizing activities are also completed as usual to active the repository in SAP. The OAC0 entry for the new respository has to point to the ACC: Version:

26 Adding a new repository in the ACC Configuration ATTENTION: in the ACC customizing, the new repository has to be listed in the list of allowedarchiveids to ensure connectivity. Example: allowedarchiveids=t1,t2,a1 Create repository in target remote archive Also, the new repository has to be made known to the remote archive following the manufacturer s instructions and procedures to create a new repository for SAP. Verify access settings Read, write and delete settings need to be reviewed for the combination of the repository and the intended access through the ACC. Access settings are the same for all repositories when handled by the ACC. Access settings are global for each connected remote archive. Example: serviceaccess.3=read,write,delete Create new ACC remote archive entry, if needed If the repository resides on a remote archive that has not yet been configured in the ACC, a new remote archive entry needs to be created. / Forth attempt against: ipaddress.3= servicename.3=/contentserver/contentserver.dll Version:

27 serviceport.3=1090 serviceaccess.3=read 4. Configuring SAP for HTTPS HTTPS configuration is added to each Content Repository configuration in OAC0. After entering Full Administration mode, enter %HTTPS in the transaction code field and hit return. A line with two hidden entries appears along with an additional field for an HTTPS (SSL) port number. A drop down menu allows you to select the appropriate HTTPS mode. Choose HTTPS preferred as the mode with the highest compatibility to server backend configurations. The server certificate also needs to be installed in SAP using transaction STRUST. Use STRUST to import the certificate (.cer file), not the root certificate. The certificate should be installed in category SSL-Client SSl-Client (Standard). In the Import Certificate pop-up enter the path for the.cer file and select Binary as file format. Once added, restart the ICM-Server (transction SMICM). Version:

28 8. SSL Configuration 1. Running Tomcat on HTTPS (SSL on incoming requests) In order to run Tomcat on HTTPS, a certificate store needs to be created to store the certificate and the certificate of the certificate authority (CA) to verify the certificate chain. Certificates can be obtained from your IT security team or from public certificate authorities. For testing purposes, self-signed certificates can be used. Creating a Self-Signed CA and a derivitive Certificate Your Java run-time installation includes a service tool called keytool, which is available on Unix and Windows. On OSX (Apple Unix), you can use the Certificate Assistant (main drop down) in the Keychain Access Tool. The Certificate Assistant guides you through creating a self-signed CA and a derived certificate. Please create a certificate for SSL Server Authentication. Explicitly set the trust level for the self-signed CA to Always Trust. If set up correctly the derrived leaf certificate shows the key chain and is implicitly trusted by the system because the CA is trusted. On Windows the Java Keytool can be used to generate a self-signed certificate: C:\Program Files\Java\<jre release>\bin\keytool.exe Create a leaf certificate on Windows (use your server name for CN (first and last name): (Reference: C:\Program Files\Java\jre1.8.0_161\bin>keytool -genkey -alias tomcat -keyalg RSA -keystore "c:\users\local Admin\Documents\myKeystore Enter keystore password: Re-enter new password: What is your first and last name? [Unknown]: winacc What is the name of your organizational unit? [Unknown]: solutionxchg What is the name of your organization? [Unknown]: solutionxchg What is the name of your City or Locality? [Unknown]: West Chester What is the name of your State or Province? [Unknown]: PA What is the two-letter country code for this unit? [Unknown]: USA Is CN=winacc, OU=solutionXchg, O=solutionXchg, L=West Chester, ST=PA, C=USA correct? [no]: no What is your first and last name? [winacc]: winacc What is the name of your organizational unit? [solutionxchg]: Development What is the name of your organization? [solutionxchg]: solutionxchg What is the name of your City or Locality? [West Chester]: West Chester Version:

29 What is the name of your State or Province? [PA]: PA What is the two-letter country code for this unit? [USA]: US Is CN=winacc, OU=Development, O=solutionXchg, L=West Chester, ST=PA, C=US correct? [no]: yes Enter key password for <tomcat> (RETURN if same as keystore password): Warning: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore c:\users\local Admin\Documents\myKeystore - destkeystore c:\users\local Admin\Documents\myKeystore -deststoretype pkcs12". C:\Program Files\Java\jre1.8.0_161\bin>keytool -importkeystore -srckeystore "c:\users\local Admin\Documents\myKeystore" -destkeystore "c:\users\local Admin\Documents\myKeystore" -deststoretype pkcs12 Enter source keystore password: Entry for alias tomcat successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled Warning: Migrated "c:\users\local Admin\Documents\myKeystore" to Non JKS/JCEKS. The JKS keystore is backed up as "c:\users\local Admin\Documents\myKeystore.old". keytool -v -list -keystore "c:\users\local Admin\Documents\myKeystore" keytool -export -alias tomcat -storepass changeit -file "c:\users\local Admin\Documents\winacc.cer" - keystore "c:\users\local Admin\Documents\myKeystore" Certificate stored in file <c:\users\local Admin\Documents\winacc.cer> The file winacc.cer can be imported by SAP in transaction STRUST. Setting up your certificates The following procedure assumes that you have either a CA certificate and a SSL service certificate based on the CA certificate or you created a matching pair of self-signed certificated yourself. The certificates used are called (CA Root certificate and leaf certificate with DNS server names): mycaroot.p12 AllServersCACertificate.p12 Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries Alias name: myrootca Creation date: May 15, 2018 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: ADDRESS=my.address@solutionXchg.com, L=West Chester, C=US, ST=PA, OU=Development, O=solutionXchg, CN=myRootCA Version:

30 Issuer: L=West Chester, C=US, ST=PA, OU=Development, O=solutionXchg, CN=myRootCA Serial number: 2 Valid from: Mon May 14 15:52:18 EDT 2018 until: Thu May 11 15:52:18 EDT 2028 Certificate fingerprints: MD5: 4A:D8:35:60:C4:5D:87:DD:30:F2:82:83:1C:E7:A7:3C SHA1: 82:7B:3B:62:CF:17:FA:83:7C:56:C3:61:9C:EB:3F:49:11:D6:EE:44 SHA256: 29:9A:23:73:17:74:BA:DA:4F:1B:AB:28:89:85:D4:3F:04:C9:0B:3E:90:4B:47:E4:B1:94:BD:CB:D3:DA:F0:25 Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: Criticality=true BasicConstraints:[ CA:true PathLen: ] #2: ObjectId: Criticality=true ExtendedKeyUsages [ clientauth serverauth codesigning anyextendedkeyusage ] #3: ObjectId: Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] #4: ObjectId: Criticality=false SubjectAlternativeName [ DNSName: localhost DNSName: accserver DNSName: accserver1 DNSName: sapcserver DNSName: sapcserver1 DNSName: sapcserver2 ] Alias name: tomcat Creation date: May 15, 2018 Entry type: PrivateKeyEntry Certificate chain length: 2 Certificate[1]: Owner: ADDRESS=my.address@solutionXchg.com, L=West Chester, C=US, ST=PA, OU=Development, O=solutionXchg, CN=Jochen Hager Issuer: ADDRESS=my.address@solutionXchg.com, L=West Chester, C=US, ST=PA, OU=Development, O=solutionXchg, CN=myRootCA Serial number: 1 Valid from: Mon May 14 15:57:48 EDT 2018 until: Thu May 11 15:57:48 EDT 2028 Certificate fingerprints: MD5: 10:08:E4:6D:52:6D:5F:A9:69:17:3F:10:7D:A9:ED:5B SHA1: 0A:6C:9B:52:C1:8F:91:47:1F:6A:90:8B:2D:9A:04:86:ED:5D:68:8F SHA256: 3B:C2:72:55:31:21:D5:57:DB:85:73:B1:A5:1B:22:9D:76:DE:D7:4A:53:36:A9:DB:5A:81:05:EA:2D:64:6F:C3 Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: Criticality=true BasicConstraints:[ CA:false PathLen: ] #2: ObjectId: Criticality=true ExtendedKeyUsages [ clientauth Version:

31 ] serverauth codesigning anyextendedkeyusage #3: ObjectId: Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] #4: ObjectId: Criticality=false SubjectAlternativeName [ RFC822Name: my.address@solutionxchg.com DNSName: localhost DNSName: accserver DNSName: accserver1 DNSName: sapcserver DNSName: sapcserver1 DNSName: sapcserver2 ] Certificate[2]: Owner: ADDRESS=my.address@solutionXchg.com, L=West Chester, C=US, ST=PA, OU=Development, O=solutionXchg, CN=myRootCA Issuer: ADDRESS=my.address@solutionXchg.com, L=West Chester, C=US, ST=PA, OU=Development, O=solutionXchg, CN= myrootca Serial number: 2 Valid from: Mon May 14 15:52:18 EDT 2018 until: Thu May 11 15:52:18 EDT 2028 Certificate fingerprints: MD5: 4A:D8:35:60:C4:5D:87:DD:30:F2:82:83:1C:E7:A7:3C SHA1: 82:7B:3B:62:CF:17:FA:83:7C:56:C3:61:9C:EB:3F:49:11:D6:EE:44 SHA256: 29:9A:23:73:17:74:BA:DA:4F:1B:AB:28:89:85:D4:3F:04:C9:0B:3E:90:4B:47:E4:B1:94:BD:CB:D3:DA:F0:25 Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: Criticality=true BasicConstraints:[ CA:true PathLen: ] #2: ObjectId: Criticality=true ExtendedKeyUsages [ clientauth serverauth codesigning anyextendedkeyusage ] #3: ObjectId: Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] #4: ObjectId: Criticality=false SubjectAlternativeName [ DNSName: localhost DNSName: accserver DNSName: accserver1 DNSName: sapcserver DNSName: sapcserver1 DNSName: sapcserver2 ] Version:

32 Adding certificates to a Tomcat accessible keystore First you would create an empty certificate store that can be accessed by Tomcat and then load your CA signed or self-signed certificates into it. All paths and commands are tested on OSX, but would work similarly in a windows command prompt, once the file paths are adjusted. Create a new keystore named CA-based-keystore.p12: keytool -genkey -alias mycertificate -keyalg RSA -keysize storetype PKCS12 keystore /Library/Tomcat/conf/keystore/CA-based-keystore.p12 Empty the keystore: keytool -delete -alias mycertificate -keystore /Library/Tomcat/conf/keystore/CA-basedkeystore.p12 List content to show it is empty: keytool -v -list -keystore /Library/Tomcat/conf/keystore/CA-based-keystore.p12 Import CA Root certificate into the keystore: keytool -v -importkeystore -trustcacerts -srckeystore /Library/Tomcat/conf/keystore/myCARoot.p12 -srcstoretype PKCS12 -destkeystore /Library/Tomcat/conf/keystore/CA-based-keystore.p12 -deststoretype PKCS12 Import servlet certificate into the keystore (check alias of your certificate first): keytool -v -alias "myalias" -importkeystore -srckeystore /Library/Tomcat/conf/keystore/AllServersCACertificate.p12 -srcstoretype PKCS12 -destkeystore /Library/Tomcat/conf/keystore/CA-based-keystore.p12 -deststoretype PKCS12 -destalias tomcat Then in a second step, you reconfigure Tomcat to use the certificates answering an HTTPS (SSL) request. Locate the tomcat server configuration file server.xml in the <Tomcat_BaseDir>/conf directory and add the following configuration code in the SSL configuration section: <Connector port="8443" protocol="org.apache.coyote.http11.http11nioprotocol" maxthreads="200" scheme="https" secure="true" SSLEnabled="true" keystorefile="conf/keystore/ca-based-keystore.p12" keystorepass="changeit" clientauth="false" sslprotocol="tls" /> This setup would allow HTTP and HTTPS communication to the server in parallel. Testing your configuration For browsers to accept the certificates, the self-signed Root CA has to be imported into the operating system keystore and marked as trusted. Once the Root CA is fully trusted, the leaf certificate should be automatically trusted as it is based on the Root CA. On OSX, import the two certificates by double clicking or by import into the Keychain Access Tool. In the Tool, you can change the trust level of the certificates by right-clicking the certificate and choosing the Get Info option. Once the Root CA ist trusted, the lead certificate should automatically be marked with a green checkmark and labeled as valid. Version:

33 When calling Tomcat with a or with the Safari browser should recognize the certificate and display the connection as a fully trusted secured connection. The same would be true for Chrome. On Firefox, the certificate will still be marked as self-signed and will still require an initial acceptance before being trusted. 2. Calling Remote ContentServers with HTTPS (SSL on outgoing requests) To call an HTTPS service from the ACC, the Java default CA certificate keystore needs to hold the leave and root certificate for all connected servers that are connecting through HTTPS. Depending on whether you have the JDK or just the JRE installed on your server, the access paths for the cacerts Java keystore are slightly different. The following example assumes you have JDK installed. You would use keytool again to load the CA Root certificate and the leaf certificate into the cacerts keystore (commands are for OSX, sudo is required to rewrite the files; please adjust the path specifications to your Java install). For OSX: (please adjust Java installation path) sudo keytool -v -importkeystore -trustcacerts -srckeystore /Library/Tomcat/conf/keystore/myCARoot.p12 - srcstoretype PKCS12 -destkeystore /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/security/cacerts sudo keytool -v -alias "jochen hager" -importkeystore -srckeystore /Library/Tomcat/conf/keystore/AllServersCACertificate.p12 -srcstoretype PKCS12 -destkeystore /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/security/cacerts -destalias tomcat For Windows: (please adjust java installation path) (keytool in C:\Program Files\Java\jre1.8.0_161\bin; start command prompt in administrator mode to make change) keytool -v -importkeystore -trustcacerts srckeystore C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\keystore\myCARoot.p12 -srcstoretype PKCS12 -destkeystore C:\Program Files\Java\jre1.8.0_161\lib\security\cacerts keytool -v -alias "jochen hager" -importkeystore -srckeystore C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\keystore\AllServersCACertificate.p12 -srcstoretype PKCS12 -destkeystore C:\Program Files\Java\jre1.8.0_161\lib\security\cacerts -destalias tomcat For debugging or troubleshooting refer to the ACC log files and also monitor the catalina.out file in the Tomcat log directory. Common error: SEVERE:[Mon May 14 18:44: EDT 2018][servletspkg.RemoteConnector openremotegetconnection] Bad URL Open Connection - IOException javax.net.ssl.sslhandshakeexception: sun.security.validator.validatorexception: PKIX path building failed: sun.security.provider.certpath.suncertpathbuilderexception: unable to find valid certification path to requested target This error indicates that the certificates are not loaded into the correct cacerts file or the cacerts file cannot be found. Alternate certificate setup without CA root certificate setup, for trouble shooting test purposes only: keytool -genkey -v -keyalg RSA -alias tomcat -keypass changeit -storepass changeit -dname "CN=localhost, OU=MyCompanyName, O=MyOrgUnit, L=MyTown, S=MyState, C=US" -keystore C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\keystore\simpleKeyStore" -ext san=dns:winacc.myorg.com Version:

34 keytool -selfcert -v -alias tomcat -keystore C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\keystore\simpleKeyStore" -storepass changeit keytool -export -keystore C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\keystore\simpleKeyStore" -alias tomcat -file "C:\Program Files\Java\jre1.8.0_161\lib\security\tomcat.cer" keytool -keystore "C:\Program Files\Java\jre1.8.0_161\lib\security\cacerts" -importcert -alias tomcat -file "C:\Program Files\Java\jre1.8.0_161\lib\security\tomcat.cer Adjust the Tomcat server.xml file accordingly. Because a certificate create this way is not created by a trusted CA, it will always create a warning in a browser, but will function for remote calls in tests. Version:

35 9. Logging and Log Settings 1. General The ACC uses standard java logging mechanismns. Its logging is separate from Tomcat logging. There are two separate ways to configure logging. Logging can either be activated and controlled in the standard Tomcat logging.properties file, or with just one line in logging.properties, logging can be controlled by webapp installation in ${catalina.base}/webapps/solxchgserver/web- INF/classes/logging.properties. asdf 2. ACC and related Log Settings Tomcat Logging Structure Details about the Tomcat logging structure can be found in your Tomcat user and configuration manuals. Please identify your version of Tomcat and research the respective manuals online. ACC Logging Structure Whether you choose to insert details for ACC specific logging into logging.propperties or you choose to add them to the servlet specific log file, in either case, the following line has to be present in logging.properties: ## SolutionXchg - Custom SimpleFormatter Format ## MUST to be present for both variants and affects all ## logging that is based on the SimpleFormatter ## Beginning ## SolutionXchg Additions ##################### java.util.logging.simpleformatter.format = %4$s:[%1$ta %1$tb %1$td %1$tH:%tM:%1$tS.%1$tL %1$tZ %1$tY][%2$s] %5$s%6$s%n ## End ## SolutionXchg Additions ########################### Centralized ACC Logging Configuration The following configuration should be added to the tomcat logging.properties file: ## SolutionXchg - Additional File Handler ## Beginning ## SolutionXchg Additions ##################### 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler.level = FINE 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler.prefix = SolXchg-ACConnector. 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler.maxDays = 3 Version:

36 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler.formatter = java.util.logging.simpleformatter # 5SolXchg-ACConnector.java.util.logging.SimpleFormatter.format = %4$s:[%1$ta %1$tb %1$td %1$tH:%tM:%1$tS.%1$tL %1$tZ %1$tY][%2$s] %5$s%6$s%n ## End ## SolutionXchg Additions ########################### and also the following segment: ## SolutionXchg - specific handles for modules and classes ## Beginning ## SolutionXchg Additions ##################### # Specifying handler for all SolutionXchg Package servletspkg.handlers = 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler # alternative: servletspkg.handlers = 5SolXchg-ACConnector.org.apache.juli.AsyncFileHandler, java.util.logging.consolehandler # Set log level for all logging and/or specific class in SolutionXchg Package servletspkg.level = FINE servletspkg.configproperties.level = FINE servletspkg.licensekey.level = FINE ## End ## SolutionXchg Additions ########################### Webapps Specific Logging The installation package includes a sample class specific log file which can be found in the WEB- INF/resources directory. The file is named webapps.logging.properties. Making this file available as ${catalina.base}/webapps/solxchgserver/web- INF/classes/logging.properties will activate servlet specific logging configuration. This can be helpful, if multiple servlets are installed under the same Tomcat. # SolutionXchg Archive Content Connector # Copyright by Jochen Hager, 2017 ## Handler Definition - Console is catalina.out handlers = org.apache.juli.filehandler, java.util.logging.consolehandler ## Custom SimpleFormatter Format ## defined in ${catalina.base}/log/logging.properties # WARNING: There is only ONE SimpleFormatter, and the format # settings HAVE to be in the general tomcat logging.properties # file. Changes will affect all logging using the SimpleFormatter Version:

37 # INSTRUCTIONS: If missing, enter this line in # ${catalina.base}/log/logging.properties below handlers # # java.util.logging.simpleformatter.format = %4$s:[%1$ta %1$tb %1$td %1$tH:%tM:%1$tS.%1$tL %1$tZ %1$tY][%2$s] %5$s%6$s%n # # Handler specific properties. # Describes specific configuration info for Handlers. org.apache.juli.filehandler.level = FINE org.apache.juli.filehandler.directory = ${catalina.base}/logs org.apache.juli.filehandler.prefix = ${classloader.webappname}. org.apache.juli.filehandler.formatter = java.util.logging.simpleformatter # ConsoleHandler specific properties. java.util.logging.consolehandler.level = WARNING # Setting log levels on the package level and for individual classes # Priority: FileHandler.level / servletspkg.level / servletspkg.<class-name> # servletspkg.level = WARNING # servletspkg.configproperties.level = FINE # servletspkg.licensekey.level = FINE # EOF Version:

38 10. Debugging Techniques and Status Checks 1. Unix Status Checks Typical Unix commands to determine system health are df for determining the mount status of the icas mount and the percentage of storage used. The Unix command top dynamically list all active processes and their memory consumption. The Unix command ps ef grep tomcat can be used to check, if tomcat is running. On Linux, Tomcat, if set up as a service, can be restarted with Ø Ø Ø Ø root servicectl stop tomcat ps ef grep tomcat servicectl start tomcat Then reopen browser and review system status. 2. Tomcat System Logging and Status Checks Useful Tomcat logs are the localhost_access_log, organized by days. It can be turned on and off in the tomcat configuration: The logging can be disabled in the following way: Go to %SPECROOT/tomcat/conf. Make a copy of server.xml file. Change following line of the server.xml: <Valve classname="org.apache.catalina.valves.accesslogvalve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolvehosts="false" /> into: <!--<Valve classname="org.apache.catalina.valves.accesslogvalve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolvehosts="false" /> --> Restart Tomcat in order to make the change available. 3. Test Calls using curl The curl test utility available on UNIX systems is a powerful tool to perform performance tests in any installation environment. The following shell script example can be adapted to the respective test situation: # curl test command to retrieve Document >e797d07b29abf9f19b5b000c2985d91c< from >T2< curl -m5 "ACCServer:8080/solXchgServer/ACConnector?get&pVersion=0046&contRep=T2 &docid=e797d07b29abf9f19b5b000c2985d91c&compid=data" > ~/Downloads/acconnector.pdf Please contact solutionxchg for additional test support if required for extensive info, get (read/display), put/post (write/create), delete tests. Version:

39 4. Testing using standard SAP Test Transactions There is a test program that can be accessed through transaction se38 in SAP. The name is RSCMST. It is included in all SAP systems. It checks various aspects of an attached SAP ArchiveLink HTTP interface compatible archiving system. It actually creates, reads, then deletes real test documents, to be sure that the content server and this content repository are in complete operating order. The test program can also be used in conjunction with the ACC. Please use the ACC lock command to lock the ACC onto a specific remote archive. The test program also perform negative test which do not display the desired result, if the ACC retry functionality is active. For testing configuration on exit 1, use the following command: The test program RSCMST has two test options (the last two in the listing) that only apply a SAP ContentServer environment and require a specific test program to be accessible by RFC on the target server. These tests would only work if the ACC and the SAP CS are co-located on the same server as the testprogram uses the server name or IP address in the OAC0 configuration to run the RFC. For all other servers, these options are not active. With a remote archive server correctly installed and the ACC active, all tests should perform without errors. The ACC is fully SAP ArchiveLink compatible based on the RSCMST test suite. Version: