Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
thomas_jung
Developer Advocate
Developer Advocate
0 Kudos
h3. Introduction  It has been a fairly quite Friday afternoon, both here at work and on SDN. I thought it would be a good time to revisit my very first Weblog series. When I first started writing this series, it wasn't particularly technically detailed. It mostly focused on my experiences as I was beginning to do BSP development. I wanted to take a little breather and return to that style of weblog.   Now in the course of my normal week, it isn't uncommon to develop one or two new BSP applications. Some weeks they are just boring run of the mill applications. Other weeks, I find some new challenge or get to try out some new technology. This week fortunately was the later situation.   The application that I am going to discuss here is closely based upon an existing R/3 application. I commonly see questions in the SDN forums or I receive them directly pertaining to converting an existing transaction to BSP. Therefore I thought it would be useful to look at this process in detail.  h4. Web-Enabled R/3 Transaction  First of all, people often ask "Should I use BSP to Web Enable an existing transaction". Of course if you just want a straight conversion of an existing transaction to run in the browser simply to eliminate the SAPGui, there is already a great option in the form of the ITS Web Gui. But that isn't entirely what we wanted to do with this new application.   The application is going to mostly be a conversion of CV04N - the transaction that allows you to search for Document Information Records. This is a very important transaction to our company, as we rely heavily upon a lot of support documents (quality documents, engineering schematics, etc). R/3 is our master repository for these documents and they are intertwined in nearly all of our ERP functions. ** *Figure 1 - Our BSP version of CV04N *    For this web version of CV04N we needed several things. First we wanted to eliminate the need for the SAPGui to access this transaction. We have users at facilities that have not yet implemented R/3. Therefore they may not have the SAPGui installed, nor have they received any R/3 training. Yet we still need these people to be able to find and access these documents. This also means that as we create the web version of this transaction, we will strive to simplify the user interface.   The final driving reason to create a new UI in BSP for the existing application is that we needed to incorporate some company specific functionality into the process that wasn't supported via the standard transaction. This is probably the most important reason for doing any custom development - to support industry or company specific needs. I'm afraid that I can't go into the details of what specific functionality that is (I have cut those portions out of the screen shots as well), but the details don't really have much bearing on this discussion anyway. h4. How Difficult is it?  The other question that I see often is "How difficult is it to re-create such a transaction in BSP". The answer is an SAP consultants best friend - "IT DEPENDS!" I can tell you that it isn't as easy as pressing a button and magically generating a new UI. On the other hand, it doesn't have to be a major implementation either.   I have found that over the years, I have built more and more custom elements and reusable components that make the process of converting applications easier. This was by no means by first attempt at doing such a thing.   The other factor that you have to consider is how difficult will it be to interact with the application layer. This usually can be measured by how good the BAPI support for the particular application is. In this case, the Document Information System BAPIs are really good. They are well documented and I have considerable experience using them. That really wasn't an area where I had to spend much time.   The other factor that I have found that really makes a difference is where are you doing your development at. In the past we have had a 46C R/3 system. Therefore we needed a standalone WebAS 640 system to do our BSP development on. We needed to access all of our data via RFC between the two systems. This doesn't really add to much development time. However it does take time to recreate data elements (and their language dependent descriptions and help information). This process is multiplied by the number of languages you need to support.   My company is currently going through an R/3 upgrade to release ECC 5.0, so now I can do BSP development on the R/3 system. I decided to write this application on R/3 so that I could take advantage of all the language translations that are already delivered because this is based on a standard transaction. To that effect I will hardly have to translate anything.  *Figure 2 - Delivered Thai Translations* So now for the numbers. I spent about 3 and half days creating this transaction (Monday - Thursday at noon of this week). Of course there were interruptions, meetings, and phone calls to take care of (oh and the pesky little upgrade thing too). Overall I feel pretty good about the amount of time that it took. h4. Making Life Easier for the User    I wouldn't be writing about this experience if this application was a straight port of CV04N. Let's look at some of the design differences that we decided to take as we recreated the application. As you can see from Figure 1  (#Figure1), the search area is very much like the original transaction. We still have the different tabs for the various types of searches. Inside the Document Data Search we have collapsible areas (structured just like those in CV04N), however we have chosen to initially collapse the lesser used areas. For the search fields themselves, we have attempted to retrain the flexibility and capabilities of the original transaction by recreating the ABAP Select-Option style selection. We also have the field sensitive help that can be viewed from the hyper linked field titles. Our hope was with the transaction in this mode, current R/3 users will still feel comfortable with the transaction and not feel that it lacks functionality compared to its SAPGui counterpart.    Where we have deviated from the original is by displaying the search results within the same page. The selection criteria can be minimized for the full view of the results. Our users seem to be more comfortable with this combination of selection and results all within one output area.   You might notice the icons at the beginning of the results table view. They link you to the original display (CV03N), change (CV02N) and structure (CC04) transactions for an individual document. At this point, I just needed the standard SAP transactions. To launch them from my BSP application, I take advantage of the integrated ITS in WebAS 640. I wrote a simple ABAP program that will take the document keys via ITS URL and call the corresponding transaction skipping any introduction selection screens.      if p_column_key = 'DISPLAY'.      l_trans = 'ZES_ITS_CV03N'.    elseif p_column_key = 'STRUCTURE'.      l_trans = 'ZES_ITS_CC04'.    else.      l_trans = 'ZES_ITS_CV02N'.    endif.    concatenate `http://kww-`                   sy-sysid                  `s.kimball.com/sap/bc/gui/sap/its/webgui?sap-client=`                  sy-mandt                  `&~transaction=`                  l_trans                  `&DOKAR=`                  m_row_ref->dokar                  `&DOKNR=`                  m_row_ref->doknr                  `&DOKTL=`                  m_row_ref->doktl                  `&DOKVR=`                  m_row_ref->dokvr                  `&~OKCODE==ONLI`                  into url.    *Listing 1 - tableView iterator coding to create the ITS link* *Listing 2 - custom program to launch the correct transaction*       *Figure 3 - Classification Search* Moving on to the other search tabs, we look at the Classification Search. Classification in R/3 is an interesting beast. It has tremendous power, because it allows customers to define their own characteristics and allowed values. But this also poses a problem for ABAP developers that have tried to program around the classification system. From a UI standpoint classical ABAP dynpro is very lacking when trying to create dynamic elements. This normally makes generating user friendly versions of the characteristic fields quite a challenge.    Fortunately, as Figure 3  (#Figure3) shows, BSP deals with dynamic UI element creation much better. I use a little dynamic Model View Binding combined with BSP BEEs and the results are quite easy to achieve. I am even able to take the allowed values for a characteristic and populate them as a normal Drop Down List Box.factory( _value = binding_string   id =  *Listing 3 - Sample use of Dynamic Binding and BEEs*    The Object Link search area is also another area where we have deviated from the original transaction. CV04N uses a second series of tab strips to represent all the possible object types. We decided instead to use a Drop Down List Box to allow the user to choose from the possible objects. The screen then displays dynamically generated input fields that match the search criteria of selected object. This also saved development time. It was much easier and faster to code the dynamic UI logic than to create all the possible sub screen views by hand.      | [ | ] | *Figure 4 - Object Link EKPO*   | [ | ] | *Figure 5 - Object Link DRAW*       So far we have mainly looked at elements designed for the "Expert" version of this transaction. It was designed for R/3 users who wanted the maximum amount of power yet with some enhanced usability options. Yet we still have user's who may not be that R/3 savvy using this transaction. For these users, we have take a page from SAP's design book and tried to create a "Guided Procedure" for searching documents.   [ | ]
6 Comments