I apologize for what is probably a basic question, but can someone tell me how to get access to the equivalent WebClient RequestContext functions without actually using the WebClient ? To be more specific, I'm trying to write a small, prototype user interface without using the WebClient, just the Java API. I'd like to use some of the functions defined on the RequestContext class, e.g., getWIStringForState, but I don't have a RequestContext bean, similar to what is passed around between the WebClient classes & jsp's.
When I logon via a service.logon call and then use the Java API's to create & start my instance, is a RequestContext, or similar object, automatically created ? If so, how can I get access to it ?
Or if it is not automatically created, can I create my own when ... ?
I'm pretty sure what I'm trying to do is possible because I see the standard Workflow client display state information on its Work Item list. I just can't see how to get there from here.
Thank in advance
Pinned topic How to use RequestContext functions outside of WebClient
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2008-02-08T08:04:15Z at 2008-02-08T08:04:15Z by SystemAdmin
Re: How to use RequestContext functions outside of WebClient2008-02-01T10:23:43ZThis is the accepted answer. This is the accepted answer.Hi,
the RequestContext is a class that is implemented by the web client (based
on J2EE) and only available in this context.
You do not have access to this class when you write your own client based
on the plain Java API.
You'll have to write your own utility classes.
IBM WebSphere Process Server Development
Re: How to use RequestContext functions outside of WebClient2008-02-07T14:49:09ZThis is the accepted answer. This is the accepted answer.A few follow-up questions. In light of the earlier response, I tried starting a work item, via the Java API item.start(), that merely loads a dummy jsp to write a "test" message to my browser window. No RequestContext calls. This failed with "FMC01014E The PEA ....is not available". I then realized that it's probably only the WebClient that searches for jsp's matching the process/program name in webclient_root directory. Right ? If I am starting a work item via the Java API, are my only options to:
- Invoke my program in a UPES context ?
- Or, invoke it via a PEA calling a .exe or .bat file specified in the Program properties ?
Thank you again for your insight & patience.
Re: How to use RequestContext functions outside of WebClient2008-02-08T08:04:15ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
what you are asking for is totally weired.
You need to distinct between a client implementation, that drives your
workflow (create and start instances)
and an activity implementation that implements the user's workitems /
The first one can be implemented either by a 'fat' client using plain Java
API or by a web based application
(like the web client) that runs on an AppServer and a browser that runs on
the user's box.
The second one can be implemented by a 'fat' program that is invoked by
the user's PEA or by an UPES.
The web client is a specific way to handle workitems without using a PEA
or an UPES on the user's box.
Instead of starting a workitem the web client client implementation
checks-out the workitem and then acts
as an 'activity implementation' and displays the input values in a jsp.
This is the way it works. Although I am not sure what you are trying to
accomplish, I doubt, that the web client is
not flexible enough to be adapted to whatever your user's are accommodated
to. But anyway. You need to make
the basic decision whether your infrastructure is based on an AppServer -
then you can use jsp's in a browser or
on plain Java - then you probably need PEA or UPES. IF you decide to use
an AppServer, be aware that everything
except the browser application is running on the AppServer's box. If you
want to invoke a program you need to figure out
on which box it should run and you can make this happen. Otherwise use the
checkout/checkin mechanism and let the
browser act as activity implementation.
IBM WebSphere Process Server Development