
In response to 😄 The Joker Challenge, I would like to describe some details about one of my company's applications, which I presented at the last SAPhire in Lissabon. Our application deals with marketing media objects and is therefore named MMM (Marketing Media Management). It was developed to support our worldwide marketing department working on a single source of objects.
Endress+Hauser is a leading supplier of measuring instruments and automation solutions for the industrial process engineering industry with over 6000 employees in production, sales and services worldwide. Endress+Hauser ist decentralized organized with one central computer center at Weil/Rhein.
I myself work at InfoServe at Freiburg/Germany. InfoServe is Endress+Hausers own IT-Department and a certified SAP Partner (Customer Competence Center, Application hosting partner).
We are using a SAP Web Application Server 6.20 in front of a 4.6c R/3. In addition, we have 5 decentralized SAP Content Server 6.20s, 1 central SAP TREX 6.01 and 1 central SAP IGS 6.30 running. Five decentralized Windows Servers running as conversion servers are completing this picture. We have 1 Content Server and 1 Conversion Server for each major marketing department. The minor departments are working with 1 central Content Server and Conversion Server.
How do these machines work together?
The WAS is used to render the presentation layer, for user management and workflow. The backend R/3 hosts the main application logic in the form of the document management system. We use the ability of the document management system to store the originals in a HTTP content server and made conversions of checked-in originals by conversion servers on OLE basis. In the case of open formats like JPEG or GIF we use one central SAP Internet Graphic Server for conversion, for example of thumbnails. To offer full text search in PDF, Word or PowerPoint documents, we are currently integrating the text extraction and retrieval engine from SAP. The document management from SAP is the whole logical bracket around this.
Because we have started in a very early stadium of WAS 6.10, (I assume, we have been the first customer on the platform AIX and DB2/OS390) we are not using not BSP extensions, but plain HTML with an own collection of JavaScript files and cascading style sheets. One specialty is the communication between the HTML client and the HTTP content server: we use an applet that enables the user to upload/download documents directly to the content server, instead of directing the complete data from the client to the WAS, from the WAS to the backend R/3 and at last from the backend R/3 to the Content Server. We are supporting MS and SUN Java environments, but the power users are using the applet on the MS VM, because on the SUN VM there is a technical restriction for transferring data in one stream up to 30 MB. Some files are bigger: pre-press files for posterscan have more than 100 MB. With this applet we can use the whole network bandwidth.
Some last words on statistical data: I am tracking the main actions for all the application, such as login, download, and ordering. The following chart shows the login of registered users (we have also a public account also).
We have currently over 600 registered MMM users and approximately 7000 media objects stored in our content servers.
One nice feature of using the SAP Document Management System is, that we have automatically a fallback system via SAPGUI. Therefore, we have implemented all additional application logic in a rich set of BADIs.
Because our WAS hosts more than one application we have to care that a registered user can only use the application, for which he was set up (Remark: if you have a valid account on a WAS, you can call any bsp application!) Because we have one central department for maintaining user accounts, we have decided to use the profile generator to build roles also for our web applications. In our example we have:
Depending on the role, the user has the right to administer other users (yes, we have a complete user administration in BSP, too!):
Create, delete, change, lock/unlock, set up user groups and making assignments to them.
In addition, the roles steer control whether, if a user has the rights to mark a media object as final, change, create or delete them.
In other words: the complete status network, which reflects the lifecycle of a media object, is steered via underlying authorization objects. In the case a user wants to have a document completed by another person, or to make it final, we have incorporated workflows.
The application has its own login scenario. The user can decide if he wants to log on via SAP user ID or an alias (e-mail address for example).
Lets start with the first screen after the user logged on:
The page is divided into a header area, a left main working area, and a menu panel for a menu on the right-hand side.
The name in the header is supplemented with the actual role description. Clicking on the name will display the basic user master data and client settings, which can be changed by the user himself. He also can maintain his workflow substitute at this point.
The main area shows the applications home page. It is indicated that the user has left the application last time not by pressing the logout button.
Underneath is a short statistic by classified and released documents, split by storage locations (= production centers).
Below the statistic are two boxes with global and location-dependant information. There is a little content management system inside. You can see the link on the left panel. Each Infomanager can provide global information and information only for his location. The other functions on the left side can be reached via the panel, which is implemented like the outlook bar:
There is also a basket for ordering media objects (itself represented by document type in the document management system!). To prevent the user to download too many files, we have made the following restrictions: files over 10 MB cannot be downloaded, they have to be ordered. One CD Burner is assigned to each location. His daily work is to burn the ordered files to a CD. We will automate this in future by integrating specialized third party software. Communication is driven via workflow and the orders are recorded via Sales Orders in the backend system. Later on we want to also offer not only software, but also hardware, like mugs and posters. From this point on, we will use the SAP SD backend for issuing invoices.
The user can group documents to folders, so for example all media objects that are necessary to make a brochure for waste water.
Via the objects tab, the user can create or change objects. He gets an overview over his own objects, all, or only the objects, that belongs to a user group, to which he is assigned. If another user has chosen him as his workflow substitute, he will see also these objects here.
One specialty not covered by the document management system is our Favorites: they are listed by description and the amount of classification data. A mouse-over text (formatted and not available by BSPbsp extensions!) displays this data in detail!
To enable the user quickly searching or creating objects, he will be able to define favorites, which itself is a collection of data to search for documents or make the classification for new ones.
Favorites can be marked to be shared and used by other users! And last, there is an overview over the users work items.
To close this description, let us step into the search procedure via a favorite:
Clicking the spyclass icon, the system loads the pre-filled search page (the favorite can be maintained by clicking on its description):
You can see a header at the top with the amount of chosen classification data and a breadcrumb implementation.
We have grouped the whole classification characteristics of MMM into 10 groups. They are represented by 10 tabs. If a user has chosen one value, the corresponding column and tab will be indicated by another color (the color can be set by the user himself!). A description for the characteristic is also available and comes generically from the backend.
The tabs for the products and industries are more complicated, they are implemented as trees with 4 levels:
We have our complete product portfolio (some thousands of products) grouped into business area, parameter, family, and designation to give the user the chance to find the right one. Phased-out products are also displayed. The data for the tree can be maintained by the infomanagers, for example to add new products or mark others as phased-out.
The user can switch between easy and extended search views. He can create new favorites also.
Pressing the search button will gives a hit list:
The user can decide if he wants to display only thumbnails or a list with thumbnail and some text. What text (extract from the classification data) and the number of thumbnails per line is also customizable by the user himself.
Clicking on the thumbnail steps into the detail view:
If the user has the rights to change the object, he will be able to toggle into a change mode.
He can download the file marked by the radio button. If he does so, our applet comes into action:
Changing or creating a document is similar:
I have implemented the rendering of the search page and the create/change page in one way. But depending on whether a characteristic in the backend is marked for single or multiple valuations, you will get radio buttons or checkboxes.
Also, as a specialty not covered by BSP extensions, the use can deselect a selected radio button.
After saving the classification the user has two different possibilities. He can use this classification to make a mass upload from files on a dedicated file share, or proceed with uploading one single file:
Upload will be done by our applet. After reading the file, it contacts the corresponding content server at the user location and places the file via http in the content servers data base.
He can also generate a version or forward the document via workflow to another user, to complete the classification data.
We are able to decide via customizing, how the file will be converted on mime type level:
The second option is the standard procedure in the 4.6c backend, if conversion is customized. The first and the third procedure are not standard, but will become so in future.
After the upload and before conversion phase, we determine the height/width in pixels and cm, the color depth and color space. This will be done via a Java API. Therfore we have set up an RFC server and call this API via SAP JCO. In future we will do this via a enterprise Java bean, set up on the corresponding WAS J2EE Server.
Conversion via SAP IGS requires only a few seconds, because the SAP IGS can directly communicate with the SAP Content Server. Time comsuming checkin and checkout procedures have not to be done in this case. In the next year we will investigate to integrate the Graphic Server from Adobe, because the most formats can be covered with this.
As a last remark, we have all the application development done in its own namespace: /EUH/MMM:
To provide registered and public login, I have split all pages into a public and protected area. The prototype node is only to show the project team some new features.
To be very generic, we have a large number of classes.
In addition, I have written customizing transactions in ABAP for all the customizing tables inside MMM.
To get a good performance on the WAS side, I have cached all backend data by an own replication framework. On the frontend side I have used browser-compatible javascript whenever possible.
We have decided to port the whole application, which consists currently of about 97 pages, to the BSP Extension technology next year. Until the end of the year we are building interfaces for the CRM e-catalog and the Endress+Hauser official download area. Further, we want to automate the burning of ordered CDs.