Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

The ABAP Detective Meets The Watch Men

JimSpath
Active Contributor
‎10-15-2012 4:52 AM

Background

(pun intended)

You may not have heard of me.  I'm the ABAP detective.  I don't come around these fancy business joints very often, not unless I'm invited, or forced here at break point. It's not like I don't get a kick out of listening to the high rollers banter about starched collar terms like "work flow", or dropping strings of letters into conversations like they mean something important.  I'd just rather sit in a coffee shop as the regulars get off their night batch work and hear them use nice one syllable words like "job" or "fail." My intent was to place this story into a space that schedulers hang out, but all I could find was something about Redwoods.  I take no truck in that California new age mysticism; give me my timekeep in the original Swiss watch container.

I've been around the business for a few years, collecting stray data leads and making connections where I could.  My one-person shop has evolved into a tidy operation, though the hours seem too long and the pay more virtual than physical.  This contract came down the wire in a "drop everything" meeting, telegraphed Western Union-style (and yes, there used to be other telegraph companies besides them). It was an offer I could turn down, except it seemed simple enough, and I needed the work.  My plans for a leisurely stroll through the data corridors evaporated, as I faced a quick turnaround on this setup.

Initial scope

At first, this case statement seemed like a wire job, setting up a connector between two information syndicates, that should have been a piece of cake. As I got further into the logic, it began to seem more like a bad dream of MacArthur's Park. I grabbed my data scope, headed out of the Acme Building, and started looking for feeds.  The primary power grid sweeps showed me that information was flowing between the two systems; to be more specific, we had an external RFC that used an XBP to start tasks, and go easy on the CCMS.  I knew I was drifting into Jargon, and once you're there, the subways don't run at night.

After getting the basic protocols and permissions set up, I built a test plan to exercise the knobs and switches.  It's easy to assume that kicking off a running system is all there is to it, but I've learned the patience to set up longer views. The dispatcher is notified, gateways jumped, and a dialogue ensues.

Test cases

Was this an inside job or an outside job? If an inside job, everything would be neatly contained; the evidence was going to be in well-known specific transaction highways and byways. If an outside job, I'd need to tail the usual places like the train station and cab stands. After bugging the building, I settled down to watch for side effects or runaway processes, with a cup of joe and a bag of don'ts.

It wasn't too far into the evening when I spotted the user, most likely a drone, called RS_LDQ_DAEMON. The question was: was this a coincidence, or something dangerous, or just a red herring?  I called in an SM37, noting the license tag and running board.

Job
X-PERFMONCOLLECT-X IDSP1 Finished09/25/2012 16:03:42
RS_LDQ_DAEMON  IDSP1 Finished    09/25/2012 16:06:35
X-PERFMONCOLLECT-XIDSP1 Finished    09/25/2012 16:07:38
RS_LDQ_DAEMON IDSP1    Finished 09/25/2012 16:10:35
X-PERFMONCOLLECT-YIDSP1 Finished    09/25/2012 16:13:36
RS_LDQ_DAEMON IDSP1 Finished    09/25/2012 16:16:36

Dealing with the watchers

I did basic casework, looking at the office files on the LDQ daemon (full name "RS_LDQ_DAEMON"), finding a few references to mobile devices, and something called process integration, neither of which were my bailiwick. I took snapshots of the relevant reference pages, hoping my image capturing wasn't going to trigger a counter-operation.

Looked like the daemon shadowed a collector.  Was it a frame-up, or did the close appearance of the two signify something? And, what was this SQLDQMON? I made a note to check that on my next trip to the big house.

Pulling back for a longer view with a different broom, I could see the LDQ was hitting the system once per hour.  I'd never heard of such a thing, though there are lots of two-bit code segments roaming the lower reaches of the enterprise that rarely see the light of day.

I picked one of them up for questioning.  Maybe a little unorthodox, not having a search warrant, or incident ticket, but if I asked general questions, maybe I'd get valuable street information.

Your basic time sheet, nothing standing out.  Though I didn't record every detail, there was no indication of what made this culprit tick.  It wasn't set up to do routine surveillance, or have a writ enabling search and seizure, it seemed to be part of a bigger scheme.

Analyzing the log did nothing to uncover the scoop.  Job starts, one step, job done. Random numbers on a tattoo, or variant as they call it, but otherwise nada.

Code snippet

CALL METHOD cl_swnc_log=>save_to_db( )

Eventually, my detective work on this case left me with several code snippets, that line up, more or less, with the steps of a job run several minutes before the one that I'm hunting down.  There are clues about RSCOLL00 and DB13, yet no clear trail linking the predecessor with the successor.

I've run out of time on this shift to nail a culprit.  I hope there will be a sequel to this tale.

Links and references

Labels in this area
Popular Blog Posts