Toward an Operational Definition of “Robust” Enterprise SOA (or, “My Three Weeks in Development Hell”)
Recently, a global leader (#1 in its sector) headquartered in Country 1 decided to open a new plant in Country 2.
As part of this project, the SAP Competency Center at headquarters in Country 3 was tasked with providing all necessary customization of standard SAP GR (Goods Receipting), QM (Quality Inspection), and PM (Plant Maintenance) .
All was going fairly well until global PM staff from Country1 attended a demo given by Country 3 PM staff of the standard SAP PM transaction IW22 configured with two standard tabs (equipment and notification.)
This demo, of course, was held about two weeks prior to actual go-live of SAP PM in the new plant.
Well, it turned out that global PM staff from Country 1 were used to using an all-encompassing Excel spreadsheet during daily reviews of A and B rank maintenace problems.
And therefore, global PM staff from Country 1 (the ultimate “deciders” in this case) told Country 3 SAP functional/technical staff that:
1) unless they could put a custom tab into IW22 to emulate the look, feel, and contents of the Excel spreadsheet, global HQ in Country 1 would not only prohibit SAP PM from going-live in the new plant, but would also order SAP PM de-activated in every plant the company operates around the world.
2) this custom tab had to be ready in one week.
Upon analysis, the spreadsheet turned out to have the equivalent of:
a) the “header” long-text available in IW22 only via pop-up of full-screen SAPScript Editor from standad tab 1 or 2;
b) the “damage” and “cause” long-texts available in IW22 only via pop-up of full-screen editor from tab 1
c) the “activity” long-text available in IW22 only via pop-up of full-screen editor from tab 2
d) the “technician comment” long-text entered when notifications are created against orders in transactions other than IW22;
e) some custom dates/times and durations not calculated nor displayed in IW22;
f) some custom staff information not displayed in IW22;
g) at least three pictures of the equipment involved in the maintenance problem (available in IW22 only via pop-up in MS Picture Manager triggered by encapsulated functions in the GOS toolbox, and including http-type “URL” attachments and file-type “URL attachments as well as non-URL attachments stored neither on drives or web-pages.)
And therefore, the Country 3 development team negotiated for, and got, six weeks total for all coding (two weeks), unit-testing (in Dev), and system-testing (in QA).
Note! This included not only display on the new custom tab, but also:
h) entry of new long text of all five types except Technician Comments – i.e. pop-up of SAPScript Editor in four different places on tab and retrieval of text from editor for display in four different text-controls on custom tab.
i) entry of data into several custom fields
j) coordination of text-entry on the new custom tab with text-entry on the two standard SAP tabs (duplicated functionality), so that text-entry from the custom tab didn’t step on text-entry from the standard tabs and vice-versa.
k) retrieval of internal picture attachments “file://” attachments, and “http://” attachments for display in three picture-controls (and subsequent full-size display in HTML viewer on double-click events of the picture control)
So, in two weeks, here’s what the development team of 1 person (me) had to do:
1) identify the correct input/output XQQM exits and code them for the five subscreens that would have to put on the new custom IW22 tab (because of size limitations in IW22 subscreen config.)
2) See whether these exists would allow customer update of QMEL via structures passed back to the IQS0 modules from the exits, or whether the appropriate SAP-provided BAdI would have to be invoked during the actual IW22 “save”
3) Learn enough about ITX1 and IQS0 text-handling modules to be able to pop the SAPScript full-screen editor from four places on the custom tab, retrieve the new text coming back, and make sure that this text is passed to the correct update processes as well as to the “display” text-controls on the custom tab.
4) Find out where internal attachments (non-URL) attachments are being stored on the customer system and how to pass URL’s for these non-URL attachments to the load_picture method of the SAP picture control.
It turns out that it took me three weeks (not two) to get the custom tab fully operational (ready for system testing in QA.)
There were three main reasons it took three, not two weeks:
1) the customer was (and is) still storing “GOS” attachments the same way they were in 1998 (in SOFFCONT1 with no URL addressability, so we had to learn how to go from folder/doc id’s to LOIO id’s to PHIO id’s, and how to use the relevant LSO32 modules to download binaries retrieved from SOFFCONT1 to local drives so that we could re-import them with URL’s that could be passed to picture controls;
2) the XQQM customer exits allowed us to pass back our updates to our custom SAP columns in QMEL, but not our text updates, so we had to learn all about the IQS0 add-long-text functions and the IQS0 TEXT_ANLEGEN_F50 subroutine so that we could call them from the BAdI method NOTIF_EVENT_SAVE~CHANGE_DATA_AT_SAVE;
3) due to the duplicated text-entry functionality on the standard SAP tabs and the custom tab, a little care had to be exercised to make sure the left-hand (SAP) knew what the right-hand (exits/BAdI) were doing.
OK – so that’s a real-life “BPX” success story as it played-out in the ABAP Objects ECC5 world.
Could it have been done in 3 weeks in the PRESENT WDJ/WDA/SOAP world?
That is, is SAP WDJ/WDA/SOAP presently robust enough to deliver the same functionality as the new custom tab in 3 weeks?
I’m interested to know how y’all would answer this question.