How much data to move? How much data to leave behind? What to automate, and what to execute manually?  How to gracefully orchestrate and execute a data migration cutover from one system to another?  Where and how to fit the data migration plan into the overall business implementation plan?  How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!

Data Migration Testing

Processes that we have exercised and continue to exercise on a regular basis are no big deal, do not cause anxiety, or raise any blood pressures.  The daily report, the custom transaction, the interface that runs several hundred times a week – they are all second nature now.  They happen, and no one notices.

But reflect back to the very first time these processes went live.  This is precisely where you are with data migration.  For most, it is a once in a lifetime event.  It is important, then, to raise confidence levels, and reduce anxiety levels surrounding this activity.  This is achieved by practice, practice, practice.

Typically, I like to see at least three data migration test cycles executed in an isolated data migration client.  This allows for several attempts at exercising and fine-tuning the data migration plan; collecting nominal run time statistics to have some idea of how long the data migration might take; identifying and fixing any data migration program object defects; identifying and fixing any data mapping and content defects; and identifying and fixing any functional configuration issues. Each of these tasks are done with the goal of significantly improving the fallout rate with each data migration test cycle.  These data migration test cycles also give us the opportunity to practice our legacy extract skills, our fallout analysis skills, and our fallout manual cleanup skills.

Source Data Quality

Each data migration test cycle begins with the legacy or source data extract.  An important activity between data migration test cycles is the cleanup of the legacy or source data.  The data migration process will most likely discover many data problems.  Customer and vendor address data alone are enough to bring your bolt-on tax jurisdiction determination software to its knees – that zip code that is too short, too long, or just plain incorrect when combined with the associated city and state; the various abbreviations used in place of the actual city name; the city and state entered in the same field when they should have been entered into separate fields; etc.   If the source data is not fixed, your data migration test cycles will begin to look like the movie Groundhog Day.

Source data provisioning and cleanup could very well be problematic, especially in an acquisition or merger scenario where the providers are part of a different organization and have no incentive to participate in your project.  If you encounter this scenario, you will most likely need to engage the appropriate management level from your organization to have a serious discussion with the appropriate management level from the providing organization.  Recognize this, be in control, and raise that flag early.    Do not sit around for several days waiting for data to arrive, as this will only set your project behind schedule.

Data Migration Support for Other Testing

In any business project scenario, the development team will salivate at the thought of testing their customizations against your real data in the conversion test cycle box.  Likewise, the functional team will be chomping at the bit to use your real data to test configuration scenarios.  And the interface team and the data warehouse team can’t ever get enough data to play with.

While working within your three data migration test cycles, just say NO.  You absolutely need a controlled environment for data migration test cycles, and these other teams will not respect that.  They have a different focus and purpose which requires changing and manipulating degrees of freedom that you need held constant.

But, we are all on the same team trying to move the project to the finish line within the expected project timeline.  So to help your other team members, plan for additional data migration cycles to provide this data to these teams.  That’s more data migration practice for you, and it gives everyone else what they need.

The Perfect World of Data Migration

In a perfect world, for each data object to be converted:

1. The functional specification and mapping documents are well-written and clear.
2. A data load file is built exactly in conformity to the well-written functional specification and mapping documents.
3. The data migration ABAP objects are built exactly as specified by the well-written functional specification and data mapping documents.
4. No one is insisting that we move a square peg into a round hole.

In a perfect world, for each set of data that is to be migrated:

1. The legacy system data has been thoroughly cleansed.
2. The providers of the legacy data are genuinely interested in providing accurate data on time.
3. Server-resident load files in a Unicode system are correctly encoded to UTF-8.
4. A delimiter other than comma has been specified for the load file.

In a perfect world, the data migration test cycle client:

1. Is built in a box that is not the development box.
2. Is configured exactly like the client where the data migration ABAP objects were built and tested.
3. Is not open for configuration, unless by design.
4. Is not part of a transport path. to prevent the current cycle of conversion testing from being blindsided by any new configuration changes.
5. Is locked down so that only data migration and data validation tasks can be performed.
6. Is configured to handle a more background and update processes and fewer dialog processes.
7. Is built in a box that has enough disk space to be the repository for the primary load files and any intermediate processing files needed.

In a perfect world, at the project level:

1. There is an overall business cutover or implementation plan into which you can assimilate your data migration plan.
2. The data migration plan integrates nicely into the overall business cutover plan.
3. There is a strategy in place to bring the data current between the time the cutover freeze is enforced and the implementation date.

Stay Tuned!

In the real world, the fun is just beginning.  Those perfect world scenarios just never seem to happen.   But stay tuned!  In my next blog post in this series, I will discuss the details of the Data Migration Plan.  After that, in subsequent posts, I will drill down into some real world scenarios that I have encountered and discuss how I dealt with them.

• How will I ever match the inbound interface parameter “Tom” with “TOM”, or “tom”?
• How will I ever match the inbound interface parameter “Smith” with “SMITH” or “smith”?
• The ABAP WHERE clause is not case-INsensitive.
• There could be hundreds of customers named Tom Smith.
• KNA1-NAME1 and KNA1-NAME2 are not indexed fields.
• And no, we are not storing any portion of either first or last name in an existing indexed field like SORTL.
• There are well over one million customers in the database.
• We have already decided to use PI for all interfaces.
• I will have to buy the BASIS team a case of beer to get them to agree to create indices on the fields KNA1-NAME1 and KNA1-NAME2 in a table with over one million records.

I arrived at the conclusion that I need a case-insensitive database query, along with database indices created for the fields KNA1-NAME1 and KNA1-NAME2.

But, what is a case-insensitive WHERE clause?  A little research and help from colleagues revealed that many had gone before me, and this was nothing new.  To implement a case-insensitive WHERE clause in ABAP, you simply needed to use the native SQL UPPER() construct. The database system that is being used is Microsoft SQL Server, but the UPPER() function and its syntax is similar across different database platforms. This seemed like an easy nut to crack. But, as I soon found out, I actually had a lot to learn.

Take 1

The examples I found were very explicit, showing actual code snippets.  Using my research examples as a template, I built what was to be my first attempt at using native SQL in a ZTEST ABAP program:

exec sql.
  select kunnr name1 name2
    from kna1
    into table i_cust
    where upper(name1) like :l_name1
      and upper(name2) like :l_name2
endexec.

Well, as a native SQL rookie, I was stopped dead in my tracks.  Native SQL does not allow a select into a table – you can only select into a work area.

Take 2

In my ZTEST ABAP program, I changed the code to SELECT into a work area and append the work area to an internal table in a subroutine:

exec sql performing append_cust.
  select kunnr, name1, name2
    from kna1
    into :wa_cust
    where upper(name1) like :l_name1
      and upper(name2) like :l_name2
endexec.

form append_cust.
  append wa_cust to i_cust.
endform.

I really thought that this would work.  But, I was getting a syntax error from native SQL – the table name was not being recognized.  A little more research revealed that, in some cases, only UPPER CASE is valid for table names and field names.  OK.  I can handle that.

Take 3

I changed the native SQL statement to all UPPER CASE in my ZTEST ABAP program:

EXEC SQL PERFORMING APPEND_CUST.
  SELECT KUNNR, NAME1, NAME2
    FROM KNA1
    INTO :WA_CUST
    WHERE UPPER(NAME1) LIKE :L_NAME1
      AND UPPER(NAME2) LIKE :L_NAME2
ENDEXEC.

form append_cust.
  append wa_cust to i_cust.
endform.

This appearedto work just fine…  Except, I noticed that too many records were being returned.  A little more analysis showed that I was getting records from ALL clients, not just my logon client.

Take 4

Again, in my ZTEST ABAP program, specify the client:

EXEC SQL PERFORMING APPEND_CUST.
  SELECT KUNNR, NAME1, NAME2
    FROM KNA1
    INTO :WA_CUST
    WHERE UPPER(NAME1) LIKE :L_NAME1
      AND UPPER(NAME2) LIKE :L_NAME2
      AND MANDT = :L_MANDT
ENDEXEC.

form append_cust.
  append wa_cust to i_cust.
endform.

Now I was getting the results that I wanted!!!!  So, I pasted this ZTEST ABAP code into the ABAP proxy.

A syntax check of the code immediately rejected the use of subroutines – they are not allowed in OO ABAP. I suppose I should have known that.  The error message indicated that I needed to use a cursor instead of the subroutine.  So, I started cursing – a lot!!!

Take 5 (The Final Version)

Here is the final version of the code which works for OO ABAP, and, hence, the ABAP proxy:

EXEC SQL.
  OPEN CUSTCURSOR FOR
    SELECT KUNNR, NAME1, NAME2
      FROM KNA1
      WHERE UPPER(NAME1) LIKE :L_NAME1
        AND UPPER(NAME2) LIKE :L_NAME2
        AND MANDT = :L_MANDT
ENDEXEC.

DO.
  EXEC SQL.
    FETCH NEXT CUSTCURSOR INTO :WA_CUST
  ENDEXEC.

  IF SY-SUBRC NE 0.
    EXIT.
  ELSE.
    APPEND WA_CUST TO I_CUST.
  ENDIF.
ENDDO.

EXEC SQL.
  CLOSE CUSTCURSOR
ENDEXEC.

Well, I finally got it right after five tries.  As mentioned before, I found many explicit code examples, but none were for OO ABAP with a database  requiring UPPER CASE be used, so that the table and field names would be recognized in the native SQL SELECT statement.

I learned something new about SAP.  I hope that I never stop learning.  I also hope that this blog might save someone a bit of distress in trying to work through a similar situation.  Now, I just need to figure out what kind of beer to buy the BASIS team to get those indexes created…

Now, put me behind a keyboard in front of a computer application which I have never seen before. My user experience is all over the map – somewhere in the continuum between most excellent and very poor.  Some application user interfaces are extremely intuitive, well-designed and easy to navigate, logically follow the business process flow, and provide real meaningful help when needed.  Other application user interfaces are extremely difficult to navigate, are not intuitive, do not follow a logical business process flow, and offer little or no meaningful help. And sometimes in these difficult user interfaces, not only has the location of the steering wheel been moved to a totally unsuspecting location, but its appearance has been changed so that, even when I see it, I do not even recognize it as being the application’s steering wheel.

A well-engineered user interface is no accident.  It doesn’t just magically happen.  It must be woven into the fabric of the design and the code; and it should never be shoe-horned into the application as an after-thought.   It takes a lot of up front planning, designing, testing, functional effort and technical effort to produce a really good application user interface.  And yes, designing, building, testing, and implementing a good user interface for your application will extend the delivery time of whatever it is that you are building.

Why is a well-designed and ergonomic user interface so important?  You could have built the best application ever developed.  But if it is unusable, it will never get very far.   Countless hours are lost every day as thousands of frustrated users spend extra time and effort wrestling with poorly designed user interfaces, rather than focusing on their jobs.  And when the frustration levels reach a certain trigger point, the users will seek out and find alternative ways to perform their duties.

Here are a few examples of some very interesting user interface experiences that I have personally encountered.

Let’s Punish the User

I thought we had gotten over this one a long time ago, but I was bitten by it recently while I was completing a web form.  Here is the scenario:

I am completing a screen form containing several fields, and I make an entry error in one of the fields.  When I try to submit the data, the application rejects the submission, and sends me a message indicating where the error field is, and then clears all of the fields on the screen and makes me re-enter all of the data again.

Bad User!  And, because you made a mistake, you get to start the entire form all over again …   and again … and again … and again …

When Help is not Help

I am especially fond of this one.  I need help, so I look for the HELP ICON.  I find the HELP ICON (because it looks like a help icon should look, and it is located where a help icon is typically located … well, sometimes it is) and I press it.  The anticipation of actually getting the help I need is overwhelming.     And the help information finally appears on my screen and reads something like this:

The exact details of what you want to know are located somewhere in our behemoth website.   Now, we could tell you exactly where and actually help you to solve your problem very quickly,    but we’re not going to, because then you won’t have spent hours wandering aimlessly through our website’s colossal labyrinth.  And while you are in there, don’t let the Minotaur get you!   Please go to www.needleinthehay.com.

Well, at least they said “please”.

The Errant Error Message

I can’t tell you how many times I have made a data entry mistake, only to be “helped” by this not-so-helpful error message:

Incorrect Entry

This is irritating.  If I don’t know why it is incorrect, I can’t fix it!  If the application is intelligent enough to determine that the entry is incorrect, it certainly is intelligent enough to tell me which of its check rules were violated (in plain user-oriented language please).

I really like this one:

Program Error 1776

This truly tells me everything I need to know!!!  Maybe the developer knows what error 1776 is, but I don’t.  Maybe I can find the meaning of error 1776 at www.needleinthehay.com. (I hope the answer is not too close to the Minotaur’s lair.)

Hey developer – can I have your phone number so I can call you every time I see one of these messages?  Maybe then you will get the hint and stop the madness!

I’ve fallen in and I can’t get out

Sometimes, I manage to navigate to a screen that has no obvious means of escape.  So I’m trapped until I can figure out the top-secret mouse click or keystroke combination.  Should I place the blue orb on the green pedestal?  I guess I really should have left a breadcrumb trail.  Or maybe the developer was a ZORK player!  Let’s try XYZZY!!!

Just Give me a Good Example

Like pictures, a good example is worth a thousand words.  Good examples are worth their weight in gold.  A really good example can get me to where I want to be – understanding what I need to know – much more quickly than an entire chapter of words.  Good examples are hard to come by.  They require lots of thought and planning.

Here is an example of a bad example:

2  @  2   =  4         where ‘@’ is some arithmetic operation.

OK – did we add or multiply here?  Who knows?  This is totally ambiguous, and a bad example.

Here is an example of a better example:

2  @  3   =  5         where ‘@’ is some arithmetic operation.

It is obvious here that the “arithmetic operation” was addition.

The Cluttered Screen

One of my favorite games as a child was the type of puzzle where a group of objects is hidden somewhere in a very busy picture.  The names of the hidden objects are listed on the side of the page, and the object of this type of puzzle is to “find the hidden objects” that are on the list.

Some user interface designers and builders are very adept at hiding items on their incredibly busy user interface screens.   Perhaps in their youth, like me, they liked to play with “find the hidden objects” puzzles also.  The problem here is that they are designing “find the hidden objects” puzzles into their user interfaces!  Is it really necessary to squeeze in every data field and push button onto a single screen?  Is the perception here that a single screen, no matter how extremely busy, is somehow easier to use?

My end-user work instructions tell me that if I push the “show details” button, I will then know the meaning of life, the universe, and everything.  But where is the “show details” button?  I am really good at playing “Where’s Waldo”!  Just give me an hour or two and I will find it!

The Plethora of Scattered Screens

The opposite of the tightly packing everything onto a single cluttered screen is the scattering of the user interface among way too many screens.  It becomes a memory exercise to remember the user interface elements that I have already touched, and a scavenger hunt to locate the interface elements that I haven’t found yet.  Let’s see … what was that part number that I entered on screen 152?  Or was it on screen 376?  And where do I go from here to get the order number?  Does anyone have a roadmap that I can follow?

Maybe if we could consolidate the enormous number of screens down to a few that represented logical work flow groupings, I could spend less time screen hopping and be more productive.

Let’s Get Colorful and Fontsy

They use several different font styles, sizes, and colors.

I suppose that’s OK, isn’t it?  It really wasn’t too difficult to read the sentence above, was it?

Consistency is Key

Let’s examine the rental car scenario that I posed at the beginning of this blog.  The reason that I am able to quickly enter the car and drive away is because a recognized user interface standard has been established and consistently applied to all automobile makes and models.  Among the various cars that I am faced with, the gas pedal always looks like a gas pedal, and is always located on the driver’s side floor to the right.  Likewise for the steering wheel, the brake pedal, and most other major user interface elements found in a car – they all adhere to standards of look and feel and placement.

It should not be too surprising then, that the not-so-ergonomic user interfaces that I have encountered do not even recognize that a standard might even exist. The really difficult user interfaces mix things up, and change the appearance, behavior, and location of controls from screen to screen.

Summary

The ergonomic user interface – the one that is intuitive, provides real help when needed, follows an organized logical workflow, and is easy to use are important components of a really great application that end users will want to use because it actually will be the best way to do their job.

Here are a few guidelines that I use whenever I build a user interface:

1)      Totally and completely understand what the business requirements are, and what the user needs to accomplish.  This is the first and most important step to building a good user interface.

2)      Design the user interface to follow the workflow.

Organize and logically group functions together.

3)      Determine if standards exist and consistently use them everywhere.

Position controls in expected and predictable locations.

4)      Give feedback to the user in a timely manner.

Don’t wait until screen 3 to inform the user that there is a problem back on screen 1.

5)      Craft meaningful error messages in user-oriented language.

Temper the messages appropriately – if everything is hot, then nothing is hot.

6)      Make sure that the “help” you provide really helps.

Ask the user to confirm before deleting anything.

Use list of values help whenever possible.

7)      Use default values whenever possible.

This avoids potential data entry errors and makes the user interface more efficient.

For example, if I work in warehouse 2, I should not have to enter that information every time I ship an item.

Display default values in pre-populated, grayed-out fields; but add a pushbutton to allow for the rare occasion when the user must override the default value.

8)      Keep training documents current.

As a developer, you may not own the training documents – but someone does.

There is nothing more frustrating than a training document that does not match the actual program behavior screen for screen and mouse click for mouse click.

I hope that this blog can provide some useful hints for building effective and efficient user interfaces.  Please reply to this blog if you have any most interesting user interface stories that you would like to share with our readers.

The reduction at segment level (see also Note 301223) was facilitated in order to be able to copy message type HRMD_A. This involved setting the reduction at field level, which was not taken into account in the code because it is not possible to centrally determine which fields are mandatory and which are dependent for all country versions. In addition, for one info type there may several records for different periods of time, which may also cause a problem when you are reducing fields.

So, in essence, field-level reduction isn’t supported for HRMD_A.  The solution supplied in the OSS note suggests creating user-exit code to filter out the unwanted fields.  I already have implemented BADI HRALE00OUTBOUND_IDOC to add some other processing logic (if you’re lucky I’ll cover that logic in this blog, too), so I have a module in which I can place the code. And while the code to loop through an IDOC and clear out all instances of E1P0002-PERID, E1P0002-GBDAT, and E1P0002-GESCH is very easy, I can’t help but think I can make the code more useful.  You see, I hate unitasking code.  I can see it now.  If I take the shortcut path and wrote the unitasking code to clear those 3 fields, the code won’t be in production for more than a month before the requirements change and now there is another field that needs to be filtered out as well.  With unitasking code, I would have to crack open the code, create a transport, unit test, transport to Q, integration test, wait for a transport window, blah, blah, blah.  Ugh!  What a waste of time for a minor change.  We can do better.

I decided to create a multi-tasking module that will work for HRMD_A message types.  The fields to be cleared will be stored in TVARV in the format <SEGMENT>-<FIELD> (e.g. E1P0002-PERID).  That way, whenever the HR functional team wanted to filter out a new field, all they had to do was to update a TVARV variable.

To implement the solution, I created a new method called CLEAR_IDOC_FIELDS in my class implementation for BADI HRALE00OUTBOUND_IDOC.  CLEAR_IDOC_FIELDS has the same method signature as IF_EX_HRALE00OUTBOUND_IDOC~IDOC_DATA_FOR_RECEIVER_MODIFY:

The code is pretty straight forward.  To allow multiple interfaces to coexist in method CLEAR_IDOC_FIELDS, the TVARV variable that stores the fields to clear is in the format ‘ZHR_CLR_’ concatenated with the IDOC message type.

METHOD CLEAR_IDOC_FIELDS .
*----------------------------------------------------------------------*
* Class:     ZCL_IM_HRALE00OUTBOUNDIDOC                                *
* Method:    CLEAR_IDOC_FIELDS                                         *
* Author:    Craig Stasila                                             *
*----------------------------------------------------------------------*

  TYPES: BEGIN OF TY_FILTER,
           TABNAME   TYPE DFIES-TABNAME,
           FIELDNAME TYPE DFIES-FIELDNAME,
           POSITION  TYPE DFIES-POSITION,
           OFFSET    TYPE DFIES-OFFSET,
           LENG      TYPE DFIES-LENG,
        END OF TY_FILTER.

  DATA: WA_FILTER      TYPE TY_FILTER,
        LT_FILTER      TYPE TABLE OF TY_FILTER,
        LS_TABNAME     TYPE DDOBJNAME,
        LS_SAV_TABNAME TYPE DDOBJNAME.

  DATA: LS_NAME   TYPE TVARV-NAME,
        LT_TVARVC TYPE TABLE OF TVARVC,
        WA_TVARVC TYPE TVARVC.

  DATA: LT_DFIES TYPE TABLE OF DFIES,
        WA_DFIES TYPE DFIES.

  DATA: LR_SEGNAM TYPE RANGE OF EDIDD-SEGNAM,
        WR_SEGNAM LIKE LINE OF LR_SEGNAM.

  FIELD-SYMBOLS: <FS> TYPE LINE OF EDIDD_TT.

* Fields to clear are in variable
  CONCATENATE 'ZHR_CLR_' MESTYP INTO LS_NAME.

* Get list of fields to clear from TVARV
  SELECT * FROM TVARVC
    INTO TABLE LT_TVARVC
   WHERE NAME = LS_NAME
     AND TYPE = 'S'.

  CHECK SY-SUBRC = 0.

* Build list of fields to clear
  LOOP AT LT_TVARVC INTO WA_TVARVC.
    CLEAR WA_FILTER.
    SPLIT WA_TVARVC-LOW AT '-' INTO WA_FILTER-TABNAME WA_FILTER-FIELDNAME.
    CHECK SY-SUBRC = 0.

    COLLECT WA_FILTER INTO LT_FILTER.
  ENDLOOP.

  SORT LT_FILTER BY TABNAME.
  CLASS CL_ABAP_CHAR_UTILITIES DEFINITION LOAD.

* Get field offsets
  LOOP AT LT_FILTER INTO WA_FILTER.
    LS_TABNAME = WA_FILTER-TABNAME.

    IF LS_TABNAME NE LS_SAV_TABNAME.

      CALL FUNCTION 'DDIF_NAMETAB_GET'
        EXPORTING
          TABNAME   = LS_TABNAME
        TABLES
          DFIES_TAB = LT_DFIES
        EXCEPTIONS
          NOT_FOUND = 1
          OTHERS    = 2.

      IF SY-SUBRC <> 0.
        CONTINUE.
      ENDIF.

      SORT LT_DFIES BY TABNAME FIELDNAME.

    ENDIF.

    LS_SAV_TABNAME = LS_TABNAME.

    READ TABLE LT_DFIES INTO WA_DFIES
         WITH KEY TABNAME   = WA_FILTER-TABNAME
                  FIELDNAME = WA_FILTER-FIELDNAME
         BINARY SEARCH.

    CHECK SY-SUBRC = 0.

    WA_FILTER-POSITION = WA_DFIES-POSITION.
    WA_FILTER-OFFSET   = WA_DFIES-OFFSET / CL_ABAP_CHAR_UTILITIES=>CHARSIZE.
    WA_FILTER-LENG     = WA_DFIES-LENG.

    MODIFY LT_FILTER FROM WA_FILTER.

* Build segment name range
    IF SY-SUBRC = 0.
      WR_SEGNAM-SIGN   = 'I'.
      WR_SEGNAM-OPTION = 'EQ'.
      WR_SEGNAM-LOW    = WA_FILTER-TABNAME.
      COLLECT WR_SEGNAM INTO LR_SEGNAM.
    ENDIF.
  ENDLOOP.

* Loop at IDOC to clear fields
  LOOP AT IDOC_DATA ASSIGNING <FS>.
    IF <FS>-SEGNAM IN LR_SEGNAM.
      LOOP AT LT_FILTER INTO WA_FILTER WHERE TABNAME = <FS>-SEGNAM.
        CLEAR <FS>-SDATA+WA_FILTER-OFFSET(WA_FILTER-LENG).
      ENDLOOP.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

I also added the following code to IF_EX_HRALE00OUTBOUND_IDOC~IDOC_DATA_FOR_RECEIVER_MODIFY:

* Clear IDOC fields
CALL METHOD ME->CLEAR_IDOC_FIELDS
  EXPORTING
     IDOC_CONTROL = IDOC_CONTROL
     RECEIVER     = RECEIVER
     MESTYP       = IDOC_CONTROL-MESTYP
  CHANGING
     IDOC_DATA    = IDOC_DATA.

Finally, I maintained the following TVARV variable:

That’s all it takes!  Now individual field values can be easily be filtered from outbound HRMD_A IDOCs!.

UPDATE: My colleague informed me that instead of using TVARV, I should continue to use BD53 to manage the IDOC reduction and change my code to look up the field reductions in TBD24.  This would be a great idea, but my full HRMD_A solution uses custom filter objects and a custom IDOC formatting function module.  And BD53 does not play well with these customizations.

Essential Duties and Responsibilities:

• Responsible for the installation, technical administration, tuning, and monitoring of SAP ERP (& related) software including R/3 4.7, ECC 5.0 & 6.0, BW, XI 3.0/PI 7.0 & Solution Manager. Also Oracle and Microsoft SQL Server implementations on Windows platform
• Expertise in providing primary support for SAP R/3 related systems
• Apply support packages, and add-ons
• Provide 24×7 hour support for mission critical system software, possible on call schedule
• Effectively communicate and interact with technical personnel in solving complex business and technical problems
• Ability to complete tasks within critical timelines and work well in a high-energy environment

• Prepare status reports and attend status meetings
• Research and provide directions for SAP software corrections including SAP OSS notes and SAP support packages
• Manage the SAP router configuration for SAP support
• Design and document security administration policies and procedures (SOP) for the production environment and train the Helpdesk to perform basic operations tasks on SAP
• Creation of client landscapes and client copies
• Create and maintain RFC connections

Qualifications:

• Bachelors degree in computing related field
• 3+ years Basis administration experience working in a complex SAP environment. R/3 and middleware experience preferred
• Experience supporting and working in a project development and support environment with ability to diagnose and solve problems quickly
• Thorough understanding and skill in database concepts (Oracle preferred)
• Good coding, testing, and documentation skills required
• Have an analytical mind and the ability to delve into detail, but also have an interest in broader business issues
• Exceptional communications (written and oral), change leadership and customer service skills

• Experience in managing SAP environment changes and upgrades
• Forward looking approach that anticipates overall project and engagement needs
• Demonstrated customer service skills/attitude
• Demonstrated value added expertise in special areas of SAP technology
• Demonstrated ability to author technical specifications, presentations, and other documentation

Additional Requirements:

• 100% travel to client sites may be required
• US citizens/permanent residents only

My colleague, Steve Park, wrote a two part blog explaining how to turn any ABAP function into a web service.  (Find Part 1 here.  Find Part 2 here.)  But, what happens when you change the function module interface as my friend in the above example did?  SAP does not automatically update the web service interface (called the virtual interface).  You have to manually rectify this conflict.  There are two main options to do this.  Both are quite easy.  Which option you choose depends on how the external systems consuming the web service are handling changes.

Note: The examples listed below are for ECC 5.0.

Option 1: Update Virtual Interface

In cases where all systems consuming the web service will be using the new function/web service interface, when the underlying structure of complex data type changes, or when mandatory fields of a function interface are added or removed, it is best to change web service virtual interface.  The consuming application may have to re-import the WSDL to

In transaction SE80, navigate to the virtual interface for the function whose interface has changed.  Right click on the virtual interface and select “Change”.

SAP will compare the virtual interface to the function interface.  If the interfaces are different, SAP will display the following prompt.

Simply select “Yes” and SAP will update the virtual interface to match the function interface.  Once you have activated your changes, you can check the WSDL to ensure that the function interface changes have been successfully migrated to the web service virtual interface.

Option 2: Create new virtual interface version

In cases where optional fields are added to the existing function interface and/or when some of the web service consumers will NOT need to use the new function interface, it is possible to create a new virtual interface version.  This is possible only in cases where the old virtual interface can still execute the function module with the new interface without causing syntax errors.

In transaction SE80, navigate to the virtual interfaces for the function whose interface has changed.  Right click on the virtual interface node and select “Create”.

In the ensuing dialog, create a new virtual interface version with the endpoint mapped to the  function module.

Now that the virtual interface is created, create a new version of the web service.

Conclusion

Changing the web service virtual interface to match changes in the underlying function module interface is easy. Whether you choose to create a new virtual interface version, or if you choose to update the virtual interface to match the new functional interface, the process is quick and easy.

Essential Duties and Responsibilities:

• Manages day-to-day maintenance of applications & interfaces
• Develop, maintain and support interface scenarios
• Manage technical design and functional specifications for interface scenarios, identify user requirements, use critical thinking to analyze & suggest alternative designs
• Utilizes various methods and processes to determine requirements and design formal solutions in response to those requirements
• Develop test cases, conduct informal and formal testing and document test results appropriately
• Utilize technical expertise with various interfacing technologies, including IDOCs, BAPIs, ALE, EDI and applications such as XI, WebSphere DataStage TX (formerly known as Mercator), Gentran, MQ-Series, Seeberger, iWay etc.
• Provide essential knowledge transfer to junior consultants and provide ad hoc guidance
• Prepare status reports for project management and attend status meetings
• Provide guidance and expertise with SAP’s development and integration technologies including: ALE design and implementation; transport layer, environment planning, upgrades, and risk mitigation
• work with the Basis team and SAP on all aspects of system builds

Qualifications:

• Bachelors degree in computing related field
• 2-4 Years technical (hands-on) experience in SAP related interface technologies
• Experience with IDOCs, BAPIs, ALE, EDI & RFC’s
• ABAP development experience
• Excellent ability to problem solve and analyze complex issues
• Ability to work as a team player and also handle individual responsibilities
• Experience working in complex environments with defined documentation and development methodologies
• Excellent verbal and written communication skills
• Experience with SAP 4.6 or higher required.
• Very strong knowledge/expertise with SAP and ABAP
• Functional expertise in core SAP module, e.g. SD,MM or FICO, highly desirable
• SAP implementation and upgrade (desirable) experience
• Hands-on experience and technical proficiency in Object Oriented ABAP (OOPs) with expertise in RICEFW development
• Well-versed in analysis the performance and efficiency of programs and codes using the SAP tools SQL Trace & Runtime Analysis for Performance tuning
• Technical proficiency in use of OSS Notes
• Experience with defining and coding conversions and interfaces using LSMW, BAPI, IDOC, BDC, and call transaction update methods
• Hands-on experience and technical proficiency in User Exits (Field Exits, Menu Exits, Function Exits, Screen Exits, Conversion Exits, BADIs)

Additional Requirements:

• 100% travel to client sites may be required
• US citizens/permanent residents only

Required Skills Summary

• 5+ years in SAP ABAP software development
• Strong ABAP skills with significant version experience in SAP 4.6c and higher
• At least 5 full lifecycle SAP implementations
• Full understanding of the SAP transport process
• High level understanding of business processes in multiple SAP functional modules, e.g. FI, SD, MM, PP, HR, PS, PM, WM
• Experience with Enterprise Portal, Web Dynpro, and Web Methods
• SAP ABAP Certification
• Experience with 3rd party applications within SAP, e.g. Sabrix, Vistex, Vertex, etc

Primary Responsibilities

• Involved in the lifecycle of critical projects from design through go-live
• Provide technical designs from functional designs with high level coding designs
• Assist functional team with technical direction to design high quality solutions
• Code, test and implement ABAP programs and modifications based upon specifications
• Provide robust, scalable, error free and efficient technical solutions with the minimum of management supervision
• Troubleshoot, identify and resolve day to day problems that occur with programs or software
• Provide production support and technical assistance
• Assist in identifying and resolving SAP issues across multiple functional areas
• Provide problem resolution for SAP support issues to internal business partners and maintain support logs and technical documentation
• Establish coding and development standards for portal technologies
• Facilitate code reviews and identify opportunities to improve existing programs
• Resolve issues with programs that are causing system performance problems
• Research SAP/OSS notes to resolve issues
• Assist with OSS note, upgrade and support pack evaluation, installation and testing
• Prepare development estimates that will be used for project planning purposes
• Strong experience in at least one SAP functional area and/or end-to-end business process, e.g. quote to cash, procure to pay

Qualifications

• 5+ years in SAP ABAP software development
• At least five full life cycle SAP project implementations
• ABAP development and workbench experience in SAP releases 4.6c, 4.7, ECC 5.0 and ECC 6.0
• Technical skills including: interfaces/integration, BAPIs, BADIs, parallel processing, screen and dialog programming, ALV reporting, table control, user exit / customer enhancements, transaction VOFM, custom application design, performance optimization, techniques for investigating performance issues, BI, SAPscript, Smartforms, Adobe Forms, Barcoding output, EDI/IDOC/XI
• Familiarity with the SAP data dictionary in a broad range of SAP modules
• Experience creating dynamic reports and subroutine pools for dynamic programming in ABAP
• Experience with ETL concepts and implementation
• Design skills including: proven ability to take defined business needs and create designs, propose and evaluate alternatives, estimate development hours, test plans, execute positive and negative tests and validate test results
• Proven ability to execute technical design reviews and code reviews

Additional Desirable Skills

• Strong troubleshooting and code debugging skills
• Able to work with business users directly as well as technical resources in a cross-functional multidisciplinary environment
• Excellent written and verbal communication skills
• Experience with SAP version ECC 6.0 and NetWeaver Developer / Development tools (NWDS, NWDI)
• Experience with BI Explorer (Bex) Objects
• Consuming 3rd party remote systems using ABAP proxies / Web Services
• Exposing RFC-enabled function modules as a Web Service

Essential Duties and Responsibilities:

• Manages (where applicable) day-to-day configuration/maintenance of middleware technologies, including SAP PI/XI, WebSphere DataStage TX (formerly known as Mercator) & Gentran
• Manage middleware basis configuration
• Responsible for designing, coding, testing and implementing middleware interfaces
• Manages technical design and functional specifications for middleware technologies, identify user requirements, use critical thinking to analyze & make alternative suggestions, where applicable
• Work within guidelines and broadly defined direction
• Provide day-to-day direction to multiple team members. Tendency for functional- and tools- specialization in 1-3 different areas. Ability to effectively deal with 2-3 projects concurrently
• Prepare status reports and attend status meetings

Qualifications:

• Bachelors degree in computing related field
• 2-4 Years technical (hands-on) experience in middleware technogies
• Technical expertise with at least one of SAP PI/XI, WebSphere DataStage TX (formerly known as Mercator) or Gentran
• Experience with at least one of the following – IDOCs, BAPIs, ALE, EDI & RFCs
• ABAP development experience
• Excellent ability to problem solve and analyze complex issues
• Ability to work as a team player and also handle individual responsibilities
• Experience in working in complex environments with defined documentation and development methodologies
• Excellent verbal and written communication skills

Additional Requirements:

• 100% travel to client sites may be required
• US citizens/permanent residents only