Topic
  • 4 replies
  • Latest Post - ‏2008-02-08T08:04:15Z by SystemAdmin
SystemAdmin
SystemAdmin
2340 Posts

Pinned topic How to use RequestContext functions outside of WebClient

‏2008-01-31T19:24:35Z |
Hello -

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
Updated on 2008-02-08T08:04:15Z at 2008-02-08T08:04:15Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    2340 Posts

    Re: How to use RequestContext functions outside of WebClient

    ‏2008-02-01T10:23:43Z  
    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
  • SystemAdmin
    SystemAdmin
    2340 Posts

    Re: How to use RequestContext functions outside of WebClient

    ‏2008-02-06T15:12:41Z  
    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
  • SystemAdmin
    SystemAdmin
    2340 Posts

    Re: How to use RequestContext functions outside of WebClient

    ‏2008-02-07T14:49:09Z  
    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 ?
    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 ?

    Thank you again for your insight & patience.
  • SystemAdmin
    SystemAdmin
    2340 Posts

    Re: How to use RequestContext functions outside of WebClient

    ‏2008-02-08T08:04:15Z  
    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 ?
    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 ?

    Thank you again for your insight & 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