Skip to Content

I’m sure you all know the How-To-Guide regarding the Application Integrator. If not, go to and download the file “Using the Application Integrator”. I’m referring to this document, so read it first if you don’t know it.

Basically the AppIntegrator is kind of an URL iView, an iframe with a set of properties, but much more powerful. Moreover, it’s possible to create SSO to the external application.

With the Generic component of the Application Integrator, you are able to integrate external web applications and pass arbitrary parameters. Since you want to invoke a web application in an iframe, you have to assemble a http request. Therefore, you use the URLTemplate property of the generic component.

“URLTemplate: Defines a template that is processed by the template processor in order to generate the application url”

How the template processor works is described in chapter 4.3 of the referenced document. You can use tags to add variables to your template. There are a lot of pre-defined tags and context that you can use, e.g. . You also can use arbitrary tags like .

The template processor will try to resolve the variable foo in the following way:

/wp-content/uploads/2005/09/app01_40909.gif 1. He will look for a custom provider that returns a String for the input parameter “foo”. (if enabled, see General Configuration)
2. He will look for a request parameter called “foo”.
3. He will look into the component profile, if a property called “foo” is present.

This weblog is especially about the custom provider of the Application Integrator which has to be implemented according to the description in chapter 6 of the referenced document.

I encounter questions about the customer exit regularly in the forums, so I decided to explain it step by step in this weblog.

Let’s start with the assumption, that you have a web application that you want to integrate with the generic component and your URLTemplate looks like this:


<System.[SystemPropertyName]> stands for the system landscape context, the prerequisites are:

  • you have to enter a system alias in the component property “System”
  • you have to use a system template, were the properties “protocol”, “server” and “uri” are present (otherwise you’ll get an exception “invalid terminal property…”)

    <foo> is resolved according to the way described above (see image). If the template processor gets null in every of the 3 steps, he will throw an exception (“Unable to process template […] because <foo> is an invalid terminal property of the context…”).

    Now we want to fill “foo” with a custom provider, because we have to do some processing to calculate the value or the value is simply not available in one of the pre-defined contexts.

    Implementing the provider

    Open your Netweaver Developer Studio and create a new Portal Application Project. As the next step you have to adjust the build path of your application. Open your project properties, go to “Java Build Path” and open the tab “Libraries”. There you can add the appintegrator libraries as external jars or via a variable. You have to add the to the build path, it’s located in in your portalapps directory.
    Then, use the wizard to create a new Portal Service. Call it however you like, I call it FooProvider for now.
    In order to use this portal service as a custom provider you have to implement the interface ICustomerParameterProvider.

    IFooProvider now looks like this:


    import com.sapportals.portal.appintegrator.parameter.ICustomerParameterProvider;
    import com.sapportals.portal.prt.service.IService;

    public interface IFooProvider extends IService, ICustomerParameterProvider
      public static final String KEY = “”;

    Next, we have to implement the methods of ICustomerParameterProvider. Go to your imlementing class, click on “Source” -> “Implement Methods” and select all methods of ICustomerParameterProvider.

    The only method of interest is for now getParameter(..). For getProviderName() I simply return the service name(return mm_serviceContext.getServiceName();) for all other methods I return null.

    The template processor will call getParameter(“foo”) to resolve the tag <foo>. Now it’s our turn. If we return null, the template processor will proceed and look into the request. If we return a String, the template processor will replace the tag <foo> with the returned String.

    This is how my getParameter(..) method looks now:

    public String getParameter(IPortalComponentRequest request, String id) throws Throwable
        return doSomeCalculations(request, id);
      }   else
        return null;
    private String doSomeCalculations(IPortalComponentRequest request, String id)
      String value = “some_calculated_stuff”;
      return value;

    Since getParameter(..) is called for every(!) property, it’s really important to leave the method as soon as possible and return null for other properties than “foo”. Doing calculations for every property can be very expensive!!

    In the case that the FooProvider is called with a property id “foo”, you can calculate the value and return it. You’ve got a reference to the request object, so you really can do a lot of different stuff here.

    At last, we have to edit the portalapp.xml to register the FooProvider. How to do this is explained in chapter 6.1.1 of the referenced document, my portalapp.xml for the FooProvider now looks like this:

    <?xml version=”1.0″ encoding=”utf-8″?>
        <entry path=”/” name=”FooProvider” type=”service”/>
        <property name=”SharingReference” value=””/>
        <property name=”startup” value=”true”/>
        <service name=”FooProvider”>
          <property name=”className” value=””/>

    The FooProvider is ready to deploy now.
    After deployment, you can check the successful registration in the portal registry browser.
    Go to “System Administration” -> “Support” -> “Support Desk” -> “Portal Runtime” -> “Portal Registry Browser” and navigate to the path “ROOT/”


    There you should see your Provider. In my example simply “foo”.

    Testing the Provider

    In SP2 custom providers are enabled by default. Moreover, every appintegrator component will call the custom provider for every property. This can be a big performance hit! Therefore, in Netweaver releases you have a iview property “Customer Exits for ‘ParameterProvider'”, where you determine which provider the iview should use. In my example it’s “foo”, because I registered the FooProvider with the name “foo”.

    Ok, the custom provider is deployed, registered and referenced in the iview. Now it’s time to do a test. The tag <foo> should be resolved now. If there are still problems, you might activate the debug mode of the appintegrator (see Debug Mode).

    General Configuration

    As a prerequisite for using custom providers you have to enable them (for NW releases, for SP2 it’s enabled by default).
    Go to “System Administration” -> “System Configuration” -> “Service Configuration” and open “Applications” -> “” -> “Services” -> “Common_Configuration”.
    There you set the property “Use_CustomerExit_ParameterProvider” to “true” and save.


    Next, restart the application by right-clicking “” -> “Administrate”
    There you can restart the appintegrator and your change takes effect.


    Debug Mode

    Go the Common_Configuration just like it’s described in “General Configuration” and set the property “DebugMode” to “true”. Then restart the appintegrator like it’s described in “General Configuration”. When you launch the iview now, the debug screen is shown first and you can check your parameters and how they were resolved.


    You should now be able to pass arbitrary parameters to any kind of web application. But that’s not all. BWReports, BSPs, Web Dynpros, Transaction iviews etc – they are all integrated with appintegrator. Of course you can use custom providers there, too! I once implemented a custom provider, that switched the value of the iview property “System” dynamically. It was possible to connect different users to different backends with a single iview. It was also possible to switch to a different backend system at runtime with a dropdown box. How cool is that? I’m sure you get even better ideas what to accomplish, just think about it 😉

    Cheers, Karsten

To report this post you need to login first.


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

  1. Hi,
       Can you please mention the property settings in the appIntegrator iview.
       Say for example we have a url link first=1&second=2&third=3, in this scenario can you just show me where and how we need to fill the values to appintegrator iview properties. Which are the mandatory parameters particularly for this scenarios.


    1. Karsten Geiseler Post author
      Hi Abhay,

      as far as I understand your question, this is all documented in the howto guide I referenced (and it’s also outlined in my weblog).

      Regards, Karsten

  2. Yusuf Sahin

    hi Karsten,<br/><br/>how can i set <System.protocol>://<System.server> dynamically and the rest remains unchanged.<br/><br/>for accessing from Internet i need system.protocol<br/>https and another system.server that is known in internet<br/><br/>kind regards<br/><br/>ys

    1. Karsten Geiseler Post author
      Hi Yusuf.

      1. this blog is all about making parameters dynamic, so I don’t get the question.

      2. for your purpose you need a reverse proxy. at least this is how i understand your requirement.

      regards, Karsten

  3. Yusuf Sahin
    Hi Karsten

    i have a reverse proxy and it funftions wery well. my users can access to portal from intranet (http) and internet(https). This is not my problem.

    my problem is URLs created by portal depending on sytem configuration in portal. when you cofigure the systems used in Portal, you must set WAS host name, WAS path and WAS protocol.

    for example system properties

    for WebDynpro XSS

    WAS host name: epe.mycompany.com50000
    WAS path: /webdynpro/dispatcher/
    WAS protocol: http

    for IACs

    ITS host name:
    ITS path:
    ITS protocol: http

    for BSPs

    WAS host name:
    WAS path:
    WAS protocol: http

    depending on these configurations portal creats URL beginning with http://..
    That ist O.K for intranet, but unfotunately not for internet because the requests begining with http are not to forward to the reverse proxy so that rewtite rule on reverse proxy doesn’t help us.

    is it possible for you to provide a sample code to build target URL depending on ClientProtocol?



  4. Prem Mascarenhas
    Hi Karsten,

    This is one of the best blogs I’ve seen. Its not only creative but also helped me in a requirement.

    Only problem was I missed out something and was probably not in the blog too. It was the field “Customer Exits for Parameter Provider” where I added “foo”

    Just a few questions:

    1. Any changes when it comes to crystal reports?
    2. The [parameter causing the issue in crystal reports is something like this:


    Will this cause any issues if I concatenate {abc}= with 12345 in implementing class?

    Thanks again.

  5. Satya Prasad

    Hi Kirsten,<br/><br/>This is very userful blog on appintegrator. we have a special requirement. Here it is…<br/><br/>our URL template is look like this..<br/><System.protocol>://<System.server><System.uri>/<User.UserID>.xyz<br/><br/>We wanted to make sure that UserID length should be 10. If UserID length is 10 then we want to put the UserID in the template, otherwise we wanted to redirect him to error page like<br/><br/>ex: if UserID length = 10<br/> <System.protocol>://<System.server><System.uri>/<br/><br/>else <br/><System.protocol>://<System.server><System.uri>/<br/><br/>is this possible to process the <User.UserID> tag with customer exit?<br/>Can I proceed in the same way that you described in the Blog?<br/><br/>Thanks,<br/>Satya

  6. Olesya Novikova
    Hi, Karsten.
    I have a problem. I set the property “Use_CustomerExit_ParameterProvider”
    to “true” and save OR set the property “DebugMode” to “true” and save.
    Then I restart the appintegrator, but my change not takes effect.
    What I’m doing incorrectly?


  7. Group Information Technology GIT

    I’m triing to link 2 different HCM with one EP (ESS&MSS scenario).
    My idea is to make few change to the standard SAP iView … and this blog is very helpfull.

    … but the debug is not chatched if I use the property “Customer Exits for ‘Parameter Provider'” in the ESS standard iView.

    It is mandatory the Application Integrator iView usage? If yes, have we to change all the ESS&MSS iVews?

    Thanks a lot,

      1. Andrea Mello
        Hi Karsten,
        I’ve created a custom provider service that extend  ICustomerParameterProvider; then a custom WebDynpro DCs that call a BAPI and an application integrator iView.

        The configuration of the provider is done (DebugMode = true and Use_CustomerExit_ParameterProvider=true)

        Activating the debug for it all is OK (the getParameter(..) method receive my parameter tag)

        Then I try to setup the same scenario for one of the standard ESS iView, but seems that my service is not called, the debug is not activated when the iView start in the Portal.

        Looking at the SAP ESS iView seems that is not an Appliation Integrator iView but an WebDynpro iView so I done the same think for my custom webDynpro and the provider is not activated.

        I’m doing or forgetting somethink or I’ve to change all the ESS iView?


Leave a Reply