View: V_GEN_JOB_INFO on Web Dynpro: ERC_C_REQ_MGMT_UI

Hi:
Can someone tell me if I can programmatically set the attribute property of the object "INDUSTRY". I have tried using the Component Configuration, but when I do, the SAP functionality of defaulting the <Requisition Title> and <Recruiter> fields does not work, so I thought I would use "set_attribute_property" method and create an enhancement "Post-Exit" after the WDDOINIT method.
When I run through the de-bug, I see my code being hit and there are no errors, but the attribute "read-only " is not reset.
If this will not work can someone suggest a way?
Thanks,
MG

Hello MG,
Can you please share your solution. I am running into a similiar issue.
Thanks,
Jim

Similar Messages

Master/Detail Viewer Application in Web Dynpro ABAP

Hello @ll,
i search a Master/Detail Viewer Application in Web Dynpro ABAP like this in WEB Dynpro Java (show below).
http://help.sap.com/saphelp_nw04/helpdata/en/84/8bc1a36a38da41a46517b114ca0974/frameset.htm
Have anyone a tutorial or can help how i config the event "onLeadSelect".
I create a master- and detail table done all context mapping.
Thanks in advance
regards
armin

Hi Armin,
Please go through
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/7a89b067-0801-0010-8192-a9896a60938e?quicklink=index&overridelayout=true
Thanks,
Prahsant

How to execute a BI query/view from a web dynpro application?

Hi all,
I am trying to connect to a BI system from a Web Dynpro application. I have to execute a view/query and process the output in my application. Please guide me about how to establish the connection to the BI system from my web dynpro application and then execute the query/view.
I have tried executing/modelling the BI query/view using Visual Composer but I get an error saying 'QueryView Instantiation failed' when I try to drag the view/query on to the design board.
Please guide me and help me achieve this.
Thanks & Regards,
Kishan

Hi Kishan,
Define system for BI in portal and define JCo destination, then from WDJ application use can query BI.
Create the Technical System and connect with JCO Destinations
or
Connecting through the BI Connecters (ex: XMLA Connecter)
Refer below link:-
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/60f35908-ecd4-2910-6c89-e75e1054d9d1?quicklink=index&overridelayout=true
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/60f35908-ecd4-2910-6c89-e75e1054d9d1
In this document you will get details related to connector and other admin activity.
Hope this may help you.
Deepak!!!

How to pass field symbol or table from one view to another view in abap web dynpro?

I am creating an Inbound Outbound ALV report in ABAP Web Dynpro. However at selection-screen I have select options and fetching is done at view2. Problem is we can pass parameter using inbound outbound parameters but how to pass internal table or field-symbols from one view to another view? I made use of Assistance Class too but its not very clear to me. Please give me some example or code to sort this problem out.

I am creating an Inbound Outbound ALV report in ABAP Web Dynpro. However at selection-screen I have select options and fetching is done at view2. Problem is we can pass parameter using inbound outbound parameters but how to pass internal table or field-symbols from one view to another view? I made use of Assistance Class too but its not very clear to me. Please give me some example or code to sort this problem out.

Set the Web dynpro component view to other web dynpro component

I have created two web dynpro components DC1 and DC2
i have imported the usage of DC2 in DC1
i am able to create the instance of DC2 in DC1 also
but the problem is i have a view V1 in the DC1, i want to embed the V1 of DC1 into one of the DC2 views Programmatically how can i do this ?

Hi,
You can include the InterfaceView of DC1 at designTime in DC2.
But you can specify the lifeTime property to "Manual" in DC2 so that you can create the ComponentInterface of DC1 at runtime using ".createComponent()" method.
So when you run the application DC1 View will not displayed by default.
Regards, Anilkumar

Skipping first view of a Web Dynpro Application

Hi,
I have an entrance screen to a WebDynpro Component on which the user has to enter a value for an input field and select one of the processing modes( Create, Delete, Change) for this object. There are some input checks and some data are filled for the second screen when the user fills in the input field and presses one of the buttons on the screen. Now i want to open this functionality with an API to a SAPGUI based application and I would like to skip the first screen when the user gives the value of the input field and the processing mode(Display, Create or Change) on the screen. Is it possible to program a kind of CALL TRANSACTION ... SKIP FIRST SCREEN with WebDynpro applications and navigate to the second screen automatically with triggering the filling of data and checks on first screen with displayigng it?Thanks.
Regards,
Sukru

Hi,
It is possible.
I have some parameters in the at the WD application level. In the WDDOINIT of the view, im using these parameters based on
these values i'm skipping the 1st view and going to 2nd view directly.
In my 1st view, I have a input field and some button with an action to it.
for ex:
i read application parameter into some variable lv_var.
and EXECUTE is the action attached to the button where im firin my plug to second view.
lv_var = wdr_task=>client_window->get_parameter( 'VAR' ).
if lv_var eq 'X'. "Skip screen
***Set the values to the Input field here
    CREATE OBJECT lref_event
      EXPORTING
        name = 'EXECUTE'.
    wd_this->ONACTIONEXECUTE( wdevent = lref_event ).
ENDIF.
endif.
In the button handler, i have my coding....
Hope this is clear.
Regards,
Lekha.

Passing parameters between views in different Web Dynpro applications

Hi everyone,
I would like to pass the value of one parameter between one view in a webdynpro application and another view that is in other webdynpro application. How can I do this in a secure way?

Hi,
Check below links for passing parameters between two applications:
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b083f76a-708c-2b10-559b-e07c36dc5440
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/91b6ad90-0201-0010-efa3-9626d2685b6e
Re: Pass parameters via POST in WDPortalNavigation.navigateAbsolute method
Regards,
Anagha

Specifying different initial views for different users in ALV web dynpro

Hi Friends,
I need to have 2 different initial view for my web dynpro application eg: View1 and View2. There will 2 group of users using the respective Views. However the first group should not be able to see other view(View2) and vice versa.
Please tell me whether it is possible and if yes then how to do it.
Regards,
Saud

Hi,
the ALV component has a public attribute - R_COMPONENT which is of type ref to IF_SALV_WD_COMPONENT_TABLE
you can call GET_PERSONALISATION on this reference to return a reference to the interface IF_SALV_WD_COMP_TABLE_PERS. This in turn has a method - SET_STANDARD_VIEW.
I think that this should allow you to set which ever view you want.
Hope it helps,
Chris

Web Dynpro List Viewer for JAVA ?

Is the Web Dynpro List Viewer available for Web Dynpro for JAVA?
The Release Notes of SAP NetWeaver 2004s about this topic are not totally clear for me.
It is always talked about Web Dynpro List Viewer for Web Dynpro in general. For more information there is only a link to the topic ALV Integration into the Web Dynpro ABAP.
I suppose, it is only available for ABAP. Am I right?

Hi Gayathri,
I just have that scenario in my mind, and certainly it's the purpose that i need to implement. However i'm tried to use only standard applications, but maybe this case it's a exceptional case
Best Regards,
Luís Bento
PS: I give you some points for your answer

Error while testing web dynpro application

Hi all,
I am trying to test a webdynpro application, following error is being generated.
The problem is, that I when I try to create a View for a Web Dynpro, the layout window reports the following error message:
ERROR
The requested URL could not be retrieved
While trying to retrieve the URL:
http://<url-of-remote-machine>:8000/sap/public/myssocntl?
The following error was encountered:
Connection to <ip-of-remote-machine> Failed
The system returned:
(110) Connection timed outThe remote host or network may be down. Please try the request again.
Your cache administrator is webmaster.
Please comment.
Thanks,
Rekha

register fully qualified doamin in your ICM file.
go to drivers->etc->hosts
write your IP address and fully qualified doamin.
thanks
Suman

Use of multiple components in ABAP WEB DYNPRO

Hi,
Am new to abap web dynpro and I just want to know whether we can use multiple components for an application in web dynpro.
Thanks ,
Dhaya.G
Edited by: Dhayalinie Ganesh on Feb 22, 2012 12:06 PM

Hi,
depending requirement of application we can use multiple components.
for example if we want to display table data into alv grid for that we can use the existing(standard component) ie: SALV_WD_TABLE .Like such a way we can use the components as per our requirements.
For importing components:
--> Go to properties tab of view of your web dynpro application
--> There you can find one button create controller usage ,click on it then import the components
Thanks&Regards
Sreenivas Pachva
Edited by: sreenivas.p on Feb 22, 2012 1:11 PM

Using EJBs in Web Dynpro

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Thanks for your reply and your suggestion. I have posted in the Web Dynpro Java forum... and suggest those wishing to participate in this thread to refer to the Web Dynpro Java forum.
As for your answer, I'm afraid it doesn't satisfy me.
Reuse is hardly an issue, since the CommandBean is specifically tailor-made for the Web Dynpro application that needs to use it. I could hardly imagine building another application that would just happen to have the exact same needs as far as data structure and processing is concerned...
As for the right Eclipse environment... the CommandBean is not an EJB artifact - it is an EJB client. The aforementioned tutorial in fact suggests creating it in the Java perspective.
But thanks anyway for your time and suggestion

Using EJBs in Web Dynpro Applications

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro Applications</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Hi Romeo,
You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
I wanted to mail you, but you have not mentioned your email in your profile.
I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.
Anyways the ball is still in your court
As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
Bye
Ankur

Execute BI Query in Web Dynpro Java

Dear All,
I have a requirement where i have to display of traffic light that sets its color based on the outcome of a SAP BEx query using Web Dynpro Java.
Please explain me the steps how to retrieve and execute the SAP BEx query using WDJ.
Thanks & Regards
Rajeev

Hi Rajeev
You can refer to the following links :
[How to execute a BI query/view from a web dynpro application?]
[How to send query parameters using BIApplicationFrame]
Regards,
Sayan Ghosh

Web Dynpro Navigation to previous screen

Hello all,
We have a requirement of displaying a Adobe form using Web-Dynpro for ABAP. This is perfectly fine and is done. Now it is like we have 2 Views in a Web-Dynpro
1. Main
2. Adobe Form display
On the 1st Page user is asked to enter certain details and then he can navigate from 1st page to the display of Adobe form. Form is also being displayed on the 2nd View. All this is absolutely fine and working.
Issue: We want to navigate back to the Main View from the Adobe form view. I have done all the required settings of plug and the navigation link from 2nd to 1st view. However, its not working at all..
I have also tried putting a break point on the button event but some how the event itself is not getting triggered. I am not able to figure out the problem as otherwise navigation is working fine with the normal web-dynpro screens.
Please help.
Regards,
Kunjal

Hi Arjun,
Thanks for the reply...
No the control is not passed to the ONACTIONBACK event as well...
This is what is creating confusion in my mind about some settings missing for the Navigation.
However, I have done following settings in the web-dynpro:
1. Define out-plug in the 2nd view.
2. Define in-plug in 1st view.
3. create navigation link in the window between 2nd view and 1st view.
4. In the Action on the button define the call to the out-plug... (in 2nd View).
Yes, it is Framework Controlled....
Please let me know if something is missing for the navigation to work.
Regards,
Kunjal

View: V_GEN_JOB_INFO on Web Dynpro: ERC_C_REQ_MGMT_UI

Similar Messages

Maybe you are looking for