You can find the detailed jobspec here. In this post I want to explore what it means to be a LiveCompare server software engineer.
LiveCompare comprises four tiers:
The ABAP tier is made up of a number of remote callable functions (RFC) that implement LiveCompare’s “SAP application” API.
The web tier is the broker between the client and server. We have four web tiers supporting the distinct UI personalities and API-level access:
Which at last brings me to the server. The server represents the heart and soul of LiveCompare. The server tier is made up of two C++-based executables:
RNSERVER.EXE runs as a Windows Service. WIPSRV.EXE is started exclusively by RNSERVER.EXE to run LiveCompare analyses.
RNSERVER.EXE exposes a data-driven COM-based API that’s accessed via this simple interface:
interface IDataServer : IDispatch
[id(1), helpstring("method Execute")] HRESULT Execute([in] BSTR in, [out, retval] BSTR* out);
All requests and responses are formatted in XML. For example, here’s a request that the web tier uses to identify the server version:
And the server responds with:
<VERSION Major=”3” Minor=”9” Revision=”0” Build=”48072” />
Note: I’ve simplified the request and response a little bit for clarity.
The web tier converts this to HTML using XSLT which the browser displays as:
The server receives requests from the web tier and either satisfies them directly or invokes LiveCompare RFCs in the ABAP tier via the SAP NetWeaver RFC SDK or spins up a child WIPSRV.EXE process to handle the request. RNSERVER.EXE communicates with WIPSRV.EXE by sending XML over http. WIPSRV.EXE uses the same COM API as the web tier to request services of RNSERVER.EXE.
Every LiveCompare analysis is based on a workflow. Here’s a snippet from the workflow that analyses the quality of custom ABAP code:
LiveCompare workflows are made up of three types of object:
Parameters (yellow boxes) are used to capture user input. The workflow above is rendered in the apps UI like this:
System 1 in the workflow maps to “As-is” in the apps UI. AAQ Select List in the workflow maps to “AAQ Select List” in the UI.
Actions (blue boxes) are generally one of three types: get data, analyse data, write report.
Datasets (green boxes) are the means by which data flows through the workflow.
Many of LiveCompare’s deep analyses are based on the analysis of graphs. Even deciding on the order in which to run a workflow’s actions is basically a topological sort of a dependency graph.
Some of the largest graphs feature tens of millions of nodes.
Writing efficient code to analyse these massive datasets is a crucial to the success of LiveCompare.
We use Microsoft Visual Studio 2017 to build LiveCompare. We use the STL extensively and Boost where required. LiveCompare depends on a number of third-party libraries including the AWS C++ SDK. We have chosen to baseline on C++14 given the compatibility of the libraries. We use Jira and Confluence internally to support projects and Jira ServiceDesk to support our customer helpdesk.
A typical day in the life of a LiveCompare server software engineer:
In addition you will:
Why should you work for IntelliCorp?
If you made it this far, head over to https://www.indeed.com/job/software-engineer-ee71e3ad53a94768 and apply. If you aren’t based in San Jose, don’t worry, please still apply. However, the stipulation that “Visa sponsorship for this role is not available” isn’t something we can change.