cancel
Showing results for 
Search instead for 
Did you mean: 

URL params for a Webdyn Pro application

Former Member
0 Kudos
211

Hi,

can anyone tell me, how a webdynpro application can access one or more URL parameters

which have been passed to it? And if it's possible: is there any special format that the parameter names should

have?

Thanks - Thorsten

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hello Thorsten,

I found a description for you. Hope this mechanism is described good enough

so that you can easily follow it:    

The Navigation between two different Web Dynpro Applications can be             

triggered by declaring an Exit Plug inside the Interface View Controller        

of Application 'StartApp' with a parameter named 'Url' of type string.          

The Url-parameter contains the qualified Url of the target Application          

belonging to the target component (may be the same like the start comp).        

For being able to fire this exit plug, a view controller                        

must first declare a controller usage for the Component Interface               

View Controller: wdThis.wdGet.fireExitPlug         

(url). The url to Application 'AnotherApp' can be retrieved by calling          

WDURLGenerator.getApplicationURL("local/WebDynpro_InterAppsNavigation",         

"AnotherApp") for a local DC, otherwise "com.sap/WebDynpro_InterAppsNav"        

A URL-Parameter can easily be added to this URL by simple string                

concatenation: urlToAnotherApp="?app.parameter="paramterValue;                

So the caller transfers the paramter via URL. The target (here the              

Startup-Plug-Eventhandler inside InterfaceViewController of 'AnotherApp'        

('AnotherApp' must declare which startup-plug of which                          

Interface View has to be used)) receives this URL parameter in an addi-         

tional Startup-Plug parameter named e.g. 'parameter'. Because the               

URL-parameter was added following the notation app..wdGetContext().currentContext            

Element().setReceivedParameter(parameter);    

Best regards,

Karin

Former Member
0 Kudos

Hi Karin,

does this mean that we can call the WebDynpro application opening a socket and passing the necessary parameters from ANY other application (not only WebDynpro but J2EE Web or something else).

Because there is some lack of finctionality in WebDynpro that does not allows eventing between IFrame and WebDynpro we are searching for a way to do some communication between (in our case) some applet embedded in IFrame control and the WebDynpro application. So if we can send some URL to the WebDynpro application and pass some parameters in it we can change something in the context and solve our problem.

Regards,

Metodi

Former Member
0 Kudos

Hi Metodi,

A Web Dynpro Application is addressable via a unique URL. This URL can contain additional URL-parameters of type ?app.someValue=?Hugo?

The values (of type string) of those URL-parameters starting with the prefix app. are automatically passed to an inbound plug event handler inside the Component Interface View controller (having the correct signature: e.g. when there is a URL parameter app.someValue the signature must contain a method variable named someValue of type string).

Look at the following relation queue:

Web Dynpro Application  (unique URL) -> references a Web Dynpro Root component -> contains a Component Interface View -> contains a startup plug -> contains plug parameters ?someValue? and ?anotherValue? of type string -> associated with a startup plug event handler inside the Component Interface View controller.

Target application URL:

http://p108392:50000/webdynpro/dispatcher/local/WebDynpro_InterAppsNavigation/TargetApp?app.someValu...

Processed startup plug event handler with parameter ?someValue? of type string inside the component interface view controller:

  //@@begin javadoc:onPlugDefault(ServerEvent)

  /** Declared validating event handler. */

  //@@end

  public void onPlugDefault(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent, java.lang.String someValue )

  {

    //@@begin onPlugDefault(ServerEvent)

    // the method value of method parameter 'someValue' will be automatically

    // filled with the value of the URL-parameter app.someValue

    wdThis.wdGetTargetCompController().wdGetContext().currentContextElement().setStartupParameter(parameter);

    //@@end

  }

The Web Dynpro Runtime automatically passes the value of the URL-parameter app.someValue to the eventhandler of the addressed startup plug inside the root component?s interface view controller.

From there you can store the value inside another controller context. Please pay attention to validate this value before storing it inside the context.

Best regards,

Karin

gregory_hawkins1
Employee
Employee
0 Kudos

Hi Karin,

     It sounds like Metodi and I are basically trying to solve the same problem. We have some external application happining in an IFrame of a Web Dynpro Application. After some certain point in the application being presented in the IFrame, we want the Web Dynpro application to respond.

     It seems like what you are suggesting could work, but I have one question with your answer:

     If I have the application that is presented in the IFrame then forwards to a new Web Dynpro URL that passes some parameter, how do I raise an event (or communicate in any way) from the Web Dynpro application that is now being presented through an IFrame in an embedding Web Dynpro application to the embedding Web Dynpro application itself?

     Are we saying that a portal event raised by an application that is presented through an IFrame in a Web Dynpro application will actually be passed through the IFrame such that the component in the main Web Dynpro application (the one with the IFrame) can respond to the event?

     That would be fantastic if it were true, but it seems like having the event pass through the IFrame to the Web Dynpro component may be too good to be true. This is really my preferred solution to my questions posed about the session identifier string.

     Thanks,

        --Greg