Using EJBs in Web Dynpro and others model tecnology patterns

I'm having difficults in order to implement the business logic in Java.
I did a simple application and I put all business rules inside de controller in the web dynpro. Everything is ok to users, but I know that this isn't indicate.
I tried to encapsulate de business rules and dao in a session bea, but I'm not sucessfull. I'd like to receive advices/tutorial about model, I found some treads in the forum, but almost all links in the sdn are browke. I was thinking in using hibernate and spring, but I don't know with it's a good choive to sap world.

Hi,
try these tutorials:
(ejb) https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/1f5f3366-0401-0010-d6b0-e85a49e93a5c
(hibernate) https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/14f55178-0801-0010-0bac-974ed17e51d3
Regards
Ladislav
PS. Consider rewarding helpful answers

Similar Messages

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

Tutorial "Using EJBs in Web Dynpro Applications" ClassCastException

Hi,
I went through the tutorial "Using EJBS in WebDynpro Applications" step-by-step.
If I run the application I always get the following error message:
java.lang.ClassCastException:com.sap.engine.interfaces.cross.ObjectReferenceImpl
if I try to make a lookup to the SessionBean.
I use the following code:
InitialContext ctx = new InitialContext();
facadeHome = (FacadeHome) ctx.lookup("FacadeBean"); <- the error is related to this line
facade = facadeHome.create();
I have nothing more to provide to be more specifiv.
What did I forget to specify or to define?
Thanks for any help.

Hi holger,
try to do it like this
InitialContext ctx = new InitialContext();
Object obj = ctx.lookup("FacadeBean");//where FacadeBean is your jndi name
facadeHome = (FacadeHome)PortableRemoteObject.narrow (obj,FacadeHome.class);
facade = facadeHome.create();
hope this helps,
regards,
rahul.

Web Dynpro And JDO JavaBean Model

Hello all,
I have read so many threads about the use of a JDO model within Web Dynpro components, but non of them gave me a real idea of which is the best practice to follow when communicating the business layer which is part of my JDO project with the component controller and view controllers...
There are other threads about communicating a model based on EJBs with WD components based on the command pattern, i see this cases are very likely but im not sure this is the best way to reach my goal...
Please, any help or comments would be just great...
Regards.

Hallo Jonathan,
please have a look at our Web Dynpro tutorial on how to apply the Java Bean Model Importer. It also contains some information on the intermediate command bean layer. We actually work on an extended version of this tutorial comprising a more complex business object model (with model class relations).
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webas/webdynpro/tutorial on using ejbs in web dynpro - 20.html
Regards, Bertram

Importing EJBs into web dynpros

I have created EJBS and I would like to use these EJBs in
web dynpros. How do I do it.
I think I can create a jar file for the EJBS and reference them in my Web Dynpro project but I think that is not the right way to do it.
Thanks,
PKK.

Hi Simon + Praveen,
I will try to walk you through how to do it but I think you may need a bit of experience with EJB's, Web Dynpro and NWDS to understand it right away. The following assumes you have created a session and entity bean.
First you need to make sure your table is deployed in the database that you created(dictionary perspective).
Second deploy your EJB (.ear file) to the J2EE engine (J2EE development perspective)
Third switch to Web Dynpro perspective and goto your project properties (right click on the project and click properties)
Now goto Java Build Path - libraries - add external jars and add the EJB-Jar file. then choose the tab called "order and export" and move the jar file to the top.
THIS IS A LITTLE TRICKY. Next you need to add the sharing reference. In the same properties wizard where you add the java build path select Web Dynpro References and then select the Sharing references tab. Click on Add and enter the vendor name and name of the ear file like this <vendor name>/<name of the ear file>, This is how your web dynpro knows where the ear file is on the j2ee engine. IF YOU ARE NOT SURE WHAT IT IS you need to access the J2EE visual administrator. and goto SERVER 0/Services/Deploy then select the "runtime" tab then look under Server 0/EJBContainer save all your meta data. your WD application now accesses your EJB logic.
Good luck!!
-wael
*plz dont forget the rewards?

Web Dynpro and CAF (BOs, Application Services, returning Complex Types)

Hi All,
I am trying to develop an application using Web Dynpro and CAF for days now and did not get it running.. I need some help here.
What I am trying to do / have done is the following:
- Design a Business Object (BO) in CAF
- Implement an Application Service that has a method called getAllBOs that calls the findAll method of the BO
- call this method using AWS model or EJB model in Web Dnypro, show the result in a table.
My getAllBOs returns a set of BOs (Data Type is the Complex Type of my BO in CAF). I was able to design the Application Service so that it returns a collection of BOs (using a Wrapper Comple Type), but I was never able to call the generated Web Service successfully in Web Dynpro. The WebService worked fine when testing it in wsnavigator...
However, i never got it running.. is there anybody out there who is able to explain what to do to import a AWS model or an EJB model in Werb Dynpro and particularily how to implement the stuff so that it returns a set of BOs successfully...
Thanks in advance.. Useful help is highly appreciated
Please note: THIS IS ABOUT Netweaver CE 7.1 - do not post stuff about 7.0!

Hi,
You have to return a single object from caf layer to webdynpro layer.
Since you are returning a list of BOs, create a wrapper in caf which contains the list of your BOs.
Your application service should return this wrapper.
Creating Wrapper:
1. Create a complex data type.
2. Include your BO as one of the properties in it. and set the cardinality to 0..n.
In Application service invoke your findAll() of BO and use the returned list to populate the wrapper's BO list.
Return this wrapper.
Hope it helps.
Regards,
Fazal

Web dynpro and database

I need to get to the sap db from my web dynpro, and I need to be able to save/retrieve/modify data.
Any idea how to approach it??
I've looked into creating ejbs but have been unsuccessful at finding an ejb document on how to create them and then use them in web dynpro.
If not, what other ways are to go about saving/retrieving data??
Thanks

Hey!
Try this out, it should work.. I would sugest that you use this code snipet on DAO's and put them in a java library project, and make reference to it from the web dynpro project properties so you don't have business logic on your WD Application, although it will also work in the WebDynpro if you copy/paste and customize this code
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Properties;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
     Connection conn = null;
     try {
          InitialContext dbInitContext = new InitialContext();
          Properties sysProperties = System.getProperties();
          String sysname = sysProperties.getProperty("SAPSYSTEMNAME");
          String dbName = "jdbc/" + "SAP" + sysname + "DB";
          DataSource dataSource = (DataSource) dbInitContext.lookup(dbName);
          conn = dataSource.getConnection();
          Statement stmtQ = conn.createStatement();
          ResultSet rs = stmtQ.executeQuery( "SELECT... ");
          while (rs.next()) {
               //iterate query
     } catch (NamingException e) {
          //handle exception
     } finally {
          try {
               conn.close();
          } catch (SQLException e) {
//handle exception
Cheers,
JV
Edited by: Jesus Valencia on Aug 6, 2009 11:00 AM

Creating Web Dynpro Adaptive Service Model For BW/BI Service.

Environment is BW 3.5 and Netweaver O4s SP12
I would like to create a Web Dynpro Adaptive Service Model based on BW Service.
Can this be done or is XMLA required? If I use XMLA I would like to know how this could be converted into a suitable model object to incorporate the results in Web Dynpro?
Thanks.

Even I faced the same problem , while running the project it was failing , the error was
=================================================
The initial exception that caused the request to fail, was:
   java.io.IOException: Cannot connect to http://www.dataaccess.nl/wk2006/footballpoolwebservice.wso?wsdl: www.dataaccess.nl
    at com.sap.engine.services.webservices.tools.WSDLDownloadResolver.resolveEntity(WSDLDownloadResolver.java:161)
    at com.sap.engine.services.webservices.wsdl.WSDLDOMLoader.loadDOMDocument(WSDLDOMLoader.java:1019)
    at com.sap.engine.services.webservices.wsdl.WSDLDOMLoader.loadWSDLDocument(WSDLDOMLoader.java:1126)
    at com.sap.engine.services.webservices.jaxrpc.wsdl2java.ProxyGenerator.generateProxy(ProxyGenerator.java:178)
    at com.sap.engine.services.webservices.espbase.client.dynamic.impl.DGenericServiceImpl.generateProxyFiles(DGenericServiceImpl.java:147)
    ... 43 more
==============================================
but after setting the proxy details in the visual administrator it started working , this threads details was helpful for me to solve my problem.
thanks ,
Madhusudhan

How to integrate a Smart Form in Web Dynpro and how to view it on portal?

Hi,
I have created a Smart Form in ABAP. I need to use it in Web Dynpro. How can this be done?
I want to integrate this Smart Form in a Web Dynpro Application and then display this Smart Form on the Portal (when I deploy the Web Dynpro application).
Is it compulsory to first convert the Smart Form into PDF Format? Is there some other way ??
Thanks in Advance.
Regards,
Harshada

Hi,
Go through Re: Web Dynpro and Smart Forms.
Regards,
Satyajit.

Abap web dynpro and portal events

First off, a little introduction: My name is Martin Kroppen, I am an Abap developer for SAP Netherlands, and I am currently involved in a project for hospitals to built a portal. For this, I have created 2 Abap web-dynpros, and then impemented the views as iviews in an EP. What I want to achieve is that the input view triggers the display view on a second page, and the data is shown for the values in the input view (all in the same browser window).
I am using the portal integration manager for this, with the method for relative navigation.
The navigation is working fine, only problem is that I don't know how to handle the business parameters that I send over.
My questions are:
1. is this the correct way for navigating between abap webdynpro iviews in the portal?
2. what is the correct way to read the business parameters into my context of the second Abap WD application?
I tried the solution that is described below, I could not get it to work correctly.
If you define BUSINESS_PARAMETERS as application parameters in your Web
Dynpro application and the parameter names start with ″APP″, they will
automatically be forwarded to the startup plugs of the Web Dynpro application
provided they are marked as startup parameters. In this case, keep in mind that
the iView/page used as the navigation target must be assigned to the user role.
If it is not, navigation cannot be triggered.
Hope someone can help me
Regards
Martin Kroppen

Hi,
please refer to this link for portal integration
Web Dynpro for ABAP Portal Integration [original link is broken]

Web Dynpro and Abobe Flex

Hi Folks,
I've seen a couple of responses to questions about the mixing of Web Dynpro and Adobe Flex technologies...
This thread mentions a "Flex Client" which is reportedly able to render existing Web Dynpro apps in Flex: WebDynPro ABAP in adobe flex client
This thread mentions a technology called "Web Dynpro Islands" which is apparently Flex components within Web Dynpro apps: Flex with WebDynPro
These concepts seem very different to me - the first being a run-time solution to Flex rendering and the second, design-time. In my opinion, the Flex Client sounds like a more flexible (excuse the pun) solution as it allows the designer to concentrate on application functionality and leaves the visual styling to the GUI. Following on from this thought, the Flex Client gives an added benefit in that, if the person executing the app wants to view it in the current WD style as opposed to Flex, they have this option by choosing a different rendering tool/user interface... and the underlying WD app remains untouched!
Does anyone have any thoughts on this?
On a potentially negative side of the Flex Client technology, is the this client yet another GUI tool that needs to be rolled-out and maintained on users' PCs or will it simply be a plugin that can be downloaded on-the-fly and used in a web browser (in a similar way to an ActiveX control)?
I hope this stimulates some interesting discussions...
Cheers
Glen

Thanks Thomas! I was hoping you'd be around to shed some light on this...
You're explanation of the use of Web Dynpro Islands was very useful - I was assuming that any UI elements created for Flex designer could also be created as a Web Dynpro component for the Web Dynpro designer (ABAP or Java) but you make a good point that they have different capabilities.
I think, my biggest concern was that the visual style of the WD Island/Flex component would be so different to the the rest of the WD app that it would stick out like a sore thumb but if you use the Flex Client to render it, as you suggested, then every UI element in the app should look and behave consistently... another assumption...
This makes me wonder whether we'll need to use the Flex Client for all our portal apps to keep the look-and-feel consistent throughout the portal. There's nothing worse to a user than having one UI element behave a certain way in one app and a totally different way in another - eg. compare the scrolling functionality of the WD table element to the Flex table element.
I'll look forward to hearing more about the Flex Client in the near future.
Cheer
Glen

How to use Cookies in Web DynPro?

Hello,
Is there a way to use Cookies in Web DynPro like a regular Servlet uses in it's response Object?
If yes, I could use a code example...
Roy

Hi Roy,
1. This will create a Request Objec containing all the client's request just like in a regular Servlet or does it have special considerations I should worry about?
A: If you have portal and webdynpro components, both have to use the same runtime. If you are using only webdynpro components then you can use the "Task" class. But it is a non-standard API.
Task.getCurrentTask().getWebContextAdapter().getHttpServletRequest()
2. Where do you recommend putting this statement? I assume at the wdDoInit() method right?
A: Don't put this statement in the doInit(), if you are handling some event within the component and refreshes the view, your doInit() will not get executed.
3. Is there a Response object I can create as well?
A:
HttpServletResponse response =((com.sap.tc.webdynpro.services.sal.adapter.core.IWebContextAdapter) WDWebContextAdapter.getWebContextAdapter()).getHttpServletResponse()
Regards,
Santhosh.C

JAVA, JAVA WEB dynpro and possibility of JAVA workflow

Hi all
Just a take here -- I'm just getting some feelers on the way WF SHOULD be going in future.
Since starting to use the JAVA WD system and netweaver developer studio it seems that having to encapsulate a lot of NEW Workflows as ABAP objects is going "Backwards". (Note I said NEW not EXISTING applications)
I understand that some compatability with existing systems needs to be maintained but if your user is doing all his applications from a Portal you really need the WF's to be triggered from the portal via say WEB SERVICES.
I find I'm actually using the older ERP / ECC 6.0 R/3 systems these days purely as DATA repositories and from a JAVA program can often retrieve the data via standard BAPI's and RFC calls in a JAVA or Portal application.
Isn't it about time that the workflow system as a whole was made much more JAVA and PORTAL friendly --since this is where more and more people are doing their developments from.
Since switching more or less full time over to JAVA WEB DYNPRO developments the whole development time is completed MUCH QUICKER and with many many less mistakes.
ABAP Web dynpro is also OK but it's still a little bit of a nightmare compared with JAVA when you need a lot of WEB SERVICES.
Some WF's obviously will need to remain ABAP based but newer custom WF's IMO should be WEB DYNPRO and WEB SERVICE based.
I can't think of too many large organisations who aren't making more and more use of Portals these days -- so C'mon SAP -- provide some proper Web hooks into WF's instead of us having to go through hoops and rings of writing LAST CENTURY's code to get stuff to work through a Portal.
Cheers
jimbo

Hi,
Have you checked the new BPM tool that SAP is offering? I think that it is definately a big step into to the drection that you are describing. I haven't really checked all its features and the technology that is is based on, so I am not the biggest expert of this matter.
Check for example this article to get an overview: http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b06c49b2-ac63-2c10-3d8d-d17b817ba4ca?quicklink=nw-bpm&overridelayout=true
Of course it will be a long road before this new tool will (if it will ever) replace the old ABAP based workflow engine.
I wouldn't totally agree with all the points that you presented (ABAP WD being a nighmare, etc.). Actually I think that the direction (at least in some parts) is the opposite. For example SAP seem to have replaced their "old" travel management applications (Java WD) with new ABAP WD applications, so I see that they believe more in ABAP than Java (of course there might be some financial & other reasons behind this also.). In my opinion WDA has so many advantages compared to WDJ, that I would consider carefully the options when choosing the technology (the possible better(?) compatibilitly with web services might be one of the reasons).
Regards,
Karri

Using CSS for Web dynpro application in EP

Hi,
I have some CSS (Style sheets) which I need to apply to the portal, so that all the web dynpro applications can have the same look and feel.
I read something about Theme Editor in EP. Can I somehow use that to import the CSS contents into the EP theme?
Any pointer to using CSS for Web Dynpro applications will be appreciated.
Thanks.
Puneet

Hi,
Go thorugh the follwing Web Dynpro Java
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/business_packages/a1-8-4/nw04stack09themes.zip
To know how to use it and for the steps to be followed please follow the tutorial here
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/how to edit web dynpro themes.pdf
the last url gives you a step by step procedure with wizards..
Regards,
RK

Using EJBs in Web Dynpro and others model tecnology patterns

Similar Messages

Maybe you are looking for