Hello - <br />
<br />
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 &#38; jsp's. <br />
<br />
When I logon via a service.logon call and then use the Java API's to create &#38; start my instance, is a RequestContext, or similar object, automatically created ? If so, how can I get access to it ? <br />
<br />
Or if it is not automatically created, can I create my own when ... ?<br />
<br />
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.<br />
<br />
Thank in advance

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.

Volker Hoss
IBM WebSphere Process Server Development

Thank you, Volker

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 <i>webclient_root</i> directory. Right ? If I am starting a work item via the Java API, are my only options to:<br />
<ul class="jive-dash">
<li>Invoke my program in a UPES context ?</li>
<li>Or, invoke it via a PEA calling a .exe or .bat file specified in the Program properties ?</li>
</ul>
I assume your earlier response means that there is no way to use the underlying Web Client functions without exposing the Web Client user interface ? Nothing against the WC's user interface but my users are too accustomed to the user interface of our existing, proprietary system. I've already tried all of the Web Client customization techniques listed in the programming manual, except registering my own command handlers, but I still don't have the desired flexibility. Is my assumption correct ? Suggestion ?<br />
<br />
Thank you again for your insight &#38; patience.

Hi,

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 /
todo's.
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.

Good Luck

Volker Hoss
IBM WebSphere Process Server Development