Skip to Content
If you are still with SAP version <=4.6C and wants to enjoy the benifits of BSP application for your business process in SAP. You can do that without upgraidng R3 basis version to WAS. This weblog explains the procedure for the same.

This procedure could be useful for the organizations who has requirement of web enabling some of reports or building web application for SAP transactions using BSP but they are still on version 4.6C or less and can not migrate R3 to 4.7 immediatly.

As per this procedure BSP application can be written on saperate WAS server and later when R3 is migrated to 4.7 the BSP application can be migrated to R3 4.7.

Also using this procedure you can enjoy other features of SAP WAS server like SMTP connection instead of SAP Exchange Server can be configured to SAP WAS and will connect to R3 system for process.

Step1: Installing WAS server 6.40: First you have to install a saperate instance of SAP WAS 6.40, which could be simple installation (without any SAP Modules).

Step2: Setup RFC Connection between WAS & R3 System: After finishing the necessary BASIS activities of SAP WAS you have to setup an RFC connection between SAP WAS server and SAP R3 system in transaction SM59.

Step3: SSO – Setup Trusted Relationship Between WAS/R3: For accessing SAP R3 (4.6C) RFCs you need to setup trusted relationship between R3 and WAS severver in which R3 server should be configured as Trusting System and WAS sever as Trusted System.
Once the trusted relationship has been defined between the two systems the user logs into WAS server using BSP can perform his transaction in R3 without any access issue. This is required because in normal RFC connection setup you can supply (hardcode) only one user id and password which leads to executing all R3 BAPI/transactions with that user id.

Step4: Replicating the Users of R3 to SAP WAS: As WAS server will be substitute of SAP R3 4.7 to use BSP and other latest feature till you migrate your R3 to 4.7 all the users in your R3 systems should be replicated in WAS server.

Step5: Replicating R3 Data structure/Table Structure: If your WAS server is not fully R3 Server some of your transaction data structure / table structure will not exists in WAS, you need to migrate them from existing R3 system so that it can be used in your BSP application.

Step6: Writing BSP Application: Now you can write your BSP application using HTMLB to represent the frontend and you can call the FM of R3 system by giving the RFC detination name as its on the same server.

Step7: SSO between SAP Portal / WAS / R3: If you wish to connect your BSP application to EP, you can setup the SSO between EP and WAS server and WAS server & R3 are already setup for trusted relationship which enables the complete SSO for whole landscape. User will not know how many systems are invloved. SAP EP –SSO–> SAP WAS –Trusted Rel–> SAP R3.

Step8: Process after upgrading you SAP R3: In the future when you plan for upgrading your SAP R3 server to 4.7 or higher you will have BSP engine inbuilt into the R3 system. Now you can plan to discontiue your WAS server and load all BSP application directly to the R3 server.

Here you need to check for your destination name for RFC connection because in your BSP application you would have coded the R3 destination name while calling RFM / BAPI, now either you need to parameterize this entry so that you can change it at one place to access the R3 system itself as target system.
Or if you are not able to perform the above step you can try removing the destination name code from BSP pages
Or you can setup the trusted relationship between the R3 server with itself in one RFC destination and you can use the BSP application just by transporting it to new R3 Server.

Platform independent content for Portal: By using the above method you will develop the contents which will not have any impact on your upgrade or migration of systems. The content developed on BSP will have no effect when you migrate your EP5 to EP6 and above process also tells that when you move to R3 4.7 or higher it will have no or negligible effect for transporting the contents.

To report this post you need to login first.

7 Comments

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

  1. Thomas Jung
    Step5: Replicating R3 Data structure/Table Structure: If your WAS server is not fully R3 Server some of your transaction data structure / table structure will not exists in WAS, you need to migrate them from existing R3 system so that it can be used in your BSP application.

    Actually there are several ways to avoid this. First is the BAPI Browser.  This tool will look at any BAPI or RFC on another system and build local definitions for any interfaced fields.  This is a great tool to avoid having to redefine all your data structures.  The other option that I have used in the Past is to use XML to move the data between systems. 

    Both solutions are described in Details in the following weblog series:
    BSP – a Developer’s Journal

    (0) 
    1. John Patterson
      Nice article Ajay, having gone through the excercie myself a couple of times, you have explained the necessary steps very well.

      I do think that Step 4 – replicating all users is a little excessive, depending on the scenario you would use the UME (User Management Engine) or CUA (Central User Administration) or something similar to manage users based on roles, let Basis Admin work this out for you.

      Step 4. Depending on how much control and business logic you want to put into a BSP application, some of the structures not present in the WAS server needed for integration will have to be created.

      Not taking away from the Thomas’s articles in ‘BSP – a Developer’s Journal’, which are well written and very informative, I found the way the BAPI builder did the type definitions a bit limited, take conversion exits for example which are necessary for various data objects (Equipment, WBSE, Functional Locations etc), simple type definition doesn’t handle this well at all.

      I have used XML in numerous BSP apps and found it very useful for things like simple drop downs etc. I found parsing XML data to ABAP is a little time consuming and unless used extensively detracts from rapid development, separation of concerns, tight type communication and available skillset which are often drivers for Writing BSP for SAP R3 Version <= 4.6.

      A good rule of thumb when designing BSP’s applications in this scenario is to keep as much of the business logic in the backend and avoid replication of anything if possible. Ajay and Thomas keep up the good work and thanks for sharing.

      (0) 
    2. John Patterson
      Ajay great article, having gone through this exact exercise several times the steps you outline in your weblog are exactly

      what is needed.

      As this is a forum for discussion I will offer my opinion.

      A good rule of thumb when designing and developing BSP applications which call back-end systems, keep as much of the business

      logic in back-end and out of the front-end as is possible, avoiding replication.

      Step4: you talk about replicating all users from R/3 to WAS. Depending on how you have user administration set up I would

      suggest using the User Management Engine (UME) or Central User Administration to manage role based user administration.

      Apart from being a learning exercise, I find a few of the main drivers for Writing BSP for SAP R3 Version <= 4.6 are;

      rapid development and deployment, separation of concerns (performance, stateless/stateful, ownership etc) and available skill

      sets, this in mind tight type definition in proxy call is a key factor for success.

      Step5: Replicating R3 Data structures, depending on how much business logic you have to put in the WAS app you will have to

      replicate some structures.

      Not taking away from Thomas’s series on BSP &#150; a Developer&#146;s Journal which are well written, insightful and informative. I believe that the way the BAPI

      browser creates the proxy definitions for RFC calls to be limited. Take for example conversion exits, which are needed for

      inputting and outputting various data objects (Equipment, WBSE, Functional Location etc.) the simple type definition doesn’t

      handle these at all, of course you could code you way out, but a lot easier to just create ABAP objects as per R3.

      I have used XML in a few BSP applications and I find it extremely useful for simple drop downs etc. I did find that parsing

      the data back to ABAP to be time consuming and unless well defined and used extensively detracts from rapid development. I

      believe this will get easier with future releases.

      I don&#146;t know if it will ever happen but I wouldn’t mind seeing the ability in BSP to bind to an imported XMI model designed

      in an external UML tool like you can do in JAVA webDynpro, that would mean you could easily write a BSP application on

      business data from any source structured or unstructured.

      Ajay and Thomas keep up the good work and thanks for sharing.

      (0) 
    3. John Patterson
      Ajay great article, having gone through this exact exercise several times the steps you outline in your weblog are exactly what is needed.

      As this is a forum for discussion I will offer my opinion.

      A good rule of thumb when designing and developing BSP applications which call back-end systems, keep as much of the business logic in back-end and out of the front-end as is possible, avoiding replication.

      Step4: you talk about replicating all users from R/3 to WAS. Depending on how you have user administration set up I would suggest using the User Management Engine (UME) or Central User Administration to manage role based user administration.

      Apart from being a learning exercise, I find a few of the main drivers for ‘Writing BSP for SAP R3 Version <= 4.6’ are rapid development and deployment, separation of concerns (performance, stateless/stateful, ownership etc) and available skill sets, this in mind tight type definition in proxy call is a key factor for success.

      Step5: Replicating R3 Data structures, depending on how much business logic you have to put in the WAS app you will have to replicate some structures.

      Not taking away from Thomas’s series on ‘BSP – a Developer’s Journal’ which are well written, insightful and informative. I believe that the way the BAPI browser creates the proxy definitions for RFC calls to be limited. Take for example conversion exits, which are needed for
      inputting and outputting various data objects Equipment, WBSE, Functional Location etc.) the simple type definition doesn’t handle these at ll, of course you could code you way out, but a lot easier to just create ABAP objects as per R3.

      I have used XML in a few BSP applications and I find it extremely useful for simple drop downs etc. I did find that parsing the data back to ABAP to be time consuming and unless well defined and used extensively detracts from rapid development. I believe this will get easier with future releases.

      I don&#146;t know if it will ever happen but I wouldn’t mind seeing the ability in BSP to bind an imported XMI model designed in an external UML tool like you can do in JAVA webDynpro, that would mean you could easily write a BSP application on business data from any source structured or unstructured.

      Ajay and Thomas keep up the good work and thanks for sharing. I dont know why the formatting screwed up in previous comment

      (0) 
      1. Thomas Jung
        I guess I should say that I was not advocating not recreating data structures.  I was simply offering additional solutions.  I should say that I do quite often duplicate data structures in my standalone WebAS system.  I sometimes even transport custom data structures between the two landscapes.  Usually if I am going to use the data object in a model class (most likely for data binding) I try and recreate the object.  Although I find that many of the most common business objects are present even in a standalone webas – matnr for material for instance. 

        But there are many other instances where I am calling to the backend system where the BAPI browser is a huge time saver.  I may have only used a handful of fields in my application and I can move those fields into the much larger BAPI input structures. 

        I did want to point out that I think your statement on keeping business logic in the backend is a very important one.  We follow similar very strict rules that all application data and logic must remain on the backend R/3 system.  If you start spreading logic or worst data between the two environments – things like backup and recovery become a really nightmare.

        (0) 
        1. John Patterson
          I agree with you on all points. I like the point of transporting data objects across landscapes, will have to try it, I wonder if there is an IDOC or some similar RFC’s as normally getting authority to transport takes time, especially if systems are owned by different business units.

          Other lesson learnt, mainly around performance while developing bespoke BSP’s for r/3 <= 4.6 are:
          * Avoid unnecessary backend calls
          * Keep number of data records small
          * Retrieve only data that is needed – cutdown structures
          * Reduce the number of database calls in the backend – process on mass if possible (sometimes hard if a stateless app)
          * Use db locking and SAP enqueues (ditto)
          * Ensure RFC FM’s are linear and scalable
          And going back to the original point – reduce dependendicies on business logic and business data

          (0) 
  2. Prashant Patil
    Informative article Ajay !!

    I have one doubt. If my BSP application resides on WAS6.2 and we are planning to upgrade from WAS6.2 to WAS 7.0.

    What would be the impact on BSP application. Do i need to only move transports or any core code modification would be required ?

    Thanks,
    Prashant

    (0) 

Leave a Reply