Skip to Content
Introduction
In response to 😀 The Joker Challenge, I thought I might post details about one my company’s applications. I have given details on my company’s structure and some of our applications in the past in my BSP developer’s weblogs. However I thought it might be fun to have a more complete look at a single application.

Kimball International
imageFirst some background on the company that I work for, Kimball International. Kimball is a global company with production operations in North America, Europe, and Asia. We have about 9,000 employees around the world.

Our company consists of two major divisions: Furniture and Cabinets Segment and Electronics Manufacturing Services. In the 8 years I have been with the company I have spent about an equal amount of time in both divisions. I currently work for the Electronics Division in our Global IT Department. We provide Applications Development and Support for our operations in the US, Mexico, Thailand, and Poland. All SAP applications development is centralized within our group in the US. Our group consists of five applications developers sharing the load of ABAP and .Net development. In addition we have one full time EDI developer.

Our Infrastructure
I’m not going to go into great detail about of Infrastructure because I have described it in previous WebLogs. To recap we are running SAP R/3 release 46C. However we also have a stand-alone WebAS running release 620. The application I am going to describe here today has parts that run in both systems (although it is primarily developed on WebAS 620). We are an MDMP system with English, Spanish, Polish, and Thai languages all in use. We have nearly 2000 named users in our SAP instance. This particular application however has a user base of about 200, however on any given day those 200 users are in this transaction a lot!

Our Application
The application I am going to describe to you is our ASAP database. You may be saying: Wait, I thought that ASAP was an SAP product. The roots of this application do begin a few years back in the SAP Accelerated Methodology tool – specifically the Question and Answer Database. This tool has in turn been replaced with the Solution Manager by SAP. Early in our implementation we did use the SAP ASAP database.

However it turned out to not really be a very good fit for what we wanted. We really were only using a portion of the functionality provided. We were using the ASAP database mainly to track problems and development requests. We wanted something to store our development documentation as well. Add to this the technical problems we were having with using the ASAP database at remote sites and we knew that it was time for a change. We soon began to design and build our own implementation and problem tracking database. About the only thing that is left of the original SAP ASAP database is the name and a few high level concepts.

Why I choose this application
Why did I choose this application to profile? First I am the technical owner of the system, so it was fairly easy to get permission to profile it (there were some tense moments, but in the end I was able to convince myself 🙂 ). Second, this system uses a very interesting mixture of technologies. We have a SAPGui version and a BSP version. Internally we use the IGS, BTF editor (SAPGui and BSP), Model View Controller, a custom HTTP Handler Service, SAP’s Content and Cache Server, and ABAP Persistent Classes. I can’t think of any other application that we have that uses this mixture of technology all together.

Application Overview
Let’s start off by having a look at the application itself. As I said before we have two different user interfaces to the same application: SAPGui and BSP. The SAPGui has the greater amount of functionality (mostly because it was developed first and is by consequence more mature), although the core functionality can be executed from either frontend. The following is a screenshot of the SAPGui version:
imageimage
imageimage

As you can see from the screen shot, we have a list of development issues or problems on the left hand side of the screen. On the Right hand side at the top we have all the details about that issue. The bottom part of the screen has several tabs with different functionality. On the first and second tab we have the BTF editors that allow for the creation of rich HTML-based content using a WYSIWYG editor. In addition I use the ABAP Class, CL_ABAP_GZIP, to compress the binary data that is returned from the BTF editor before storing it in the database.

image
The third tab has Linked documents. These documents can be created from templates or uploaded from the frontend. We will talk more about the technology we use to store the documents in a little bit.

image
The next tag hold User assignments and details about those assignments. We have an ALV grid on the Left Side and two more BTF editors on the right.

image The final tab has information about any CTS’s linked to this development Issue. We gather information in real time about these CTS’s using RFC calls to the R/3 System. I use an Updatable ALV Grid for the user interface on this Tab.

Use of BSP
Now for a look at where we use BSP in this application. First of all we have a second user interface to the application completely built in BSP. We created this frontend for two reasons. The first was for our new implementation sites. When we start implementing SAP at a new site, the first transaction that the users spend a lot of time in is usually this database. We ask them to begin recording their functionality gaps. Because these user’s are new to SAP and its User Interface, we wanted something a little easier and more familar for them to use. Therfore we came up with the simplified BSP User Interface. New users seem to accept a Web based application much easier than the overwhelming SAPGui. The second reason was for remote and home access to this database. When performing night support we often log solutions into this database. We wanted a user interface that would respond well to a low speed modem connection. We also didn’t necessarily want the user’s PC to have to have the full SAPGui loaded on it. The BSP application meets both of these needs nicely. The following is a screen shot of this user interface.
imageimage
imageimage

Although full featured in what it offers (create, change, and display of development issues; as well as BTF editors for the first two tabs and the documents links), you will notice that the last two tabs are missing. That is because development on the BSP version does run a little behind the SAPGui version. These last two tabs are also the least important and least used pieces of functionality.

But that isn’t the only place we use BSP technology. I mentioned before that we use BTF editors in both user interfaces. These editors are very nice WYSIWYG HTML editors. However the HTML content that they return poses a problem for traditional ABAP printing. I originally used a SmartForm to print the output. However once we switched to using the BTF editor this became a problem. The solution was to change the printing function to actually display a stateless BSP page with all the details. Users could then print from this Page without losing the formatting of the BTF sections. The following is what the printout looks like:
image

I also use this same functionality to email a copy of the Issue. In ABAP I create an HTTP client and retrieve the content for this BSP page. I then insert this content as the body of the E-mail message and send it out.

Finally I have one last place where I use BSP technology. We have several charts and graphs that project management uses to see the overall progress of development. I implement this using BSP and the SAP IGS (Internet Graphics Server).
image

Content and Cache Server
Next up, lets talk about the documents that we store in our database. Because we have implementation team members from around the world accessing this database, a good technology of storing and serving the document attachments was necessary. When we first started we simply stored links to documents on a file share. However our more remote sites had problems opening these often very large files. The solution came in the form of SAP’s PLM document management solution.

We use SAP’s content and cache Servers to store these documents. When someone creates a document, we make a BAPI call to create a Document Information Record in our R/3 system. The R/3 DIR in turn is configured to physically store the document in the SAP Content Server. Now where the real power of this solution comes to play is in the Cache server. We have placed SAP Content Cache Servers at our remote sites. The first person that requests a document from a remote content server will place that document in the cache after retrieval. All subsequent request then retrieve the document from the catch. Add to this the fact that all data traffic happens via HTTP, and you have a much nicer solution than storing your documents on a file share. Early next year we hope to add the SAP TRex search engine to this solution to add the ability to do full text searches as well.

The only problem with this solution was that users were accustomed to coping the document links into E-Mails and other Documents. Although the Content Server has an HTTP interface, the URLs are difficult to decipher and we have them configured to require the inclusion of a digital certificate. Therefore we came up with the solution to write our own ICM handler to access documents. This handler class takes in the document keys from the supplied URL and calls the necessary BAPIs to generate the complex URL with the included digital signature. It also allows us to give out Anonymous read only access to our managed documents. The ICM service for this class is setup with an Anonymous ID that has read-only rights to call the document BAPIs.

Persistent Classes
The last thing that I wanted to describe was our use of ABAP Persistent Classes. With two user interfaces to the same application, traditionally I would have had a lot of redundant coding. However I was able to eliminate a lot of redundancy by the heavy use of ABAP OO. First of all, my database layer is completely writen in the new ABAP Persistent classes. You won’t find an Update or Insert statement in my code! These Persistent classes have made it very easy to add new fields to the application as it has grown. For the next layer up, I have created a single Object Class that encapsulates all of my Persistent Classes. That way the final application class can work with data at the logical level (as a development issue, instead of the many tables and persistent classes that make up a single issue). This use of OO made it possible to create two user interfaces. It also has had a tremendous impact on how easy and fast we have been able to enhance this system.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Craig Cmehil
    Very nice, I am just waiting for approval from my company to post some of ours.

    If nothing else Brian will get a peek at one of the big ones I am working right now but I hope to share it here as well.

    Craig

    (0) 

Leave a Reply