BPM, Workflow, and Case

BPM, Workflow, and Case

Come for answers. Stay for best practices. All we’re missing is you.

 View Only
Expand all | Collapse all

Custom toolkit with service flows, that have multiple JAR dependencies - best practices

  • 1.  Custom toolkit with service flows, that have multiple JAR dependencies - best practices

    Posted Tue June 27, 2023 12:53 PM

    Hello colleagues,

    we are starting new project for one of our customers, where we are going to build Case solution with several activities, which will be modeled in BPM workflows. Also we configured external FileNet and ICN server to communicate with BAW instance.

    We have couple of use-cases, where we must implement some custom logic, for example:

    • Give me list of case instances IDs, which are related. Let's assume I have Case A, Case B, Case C and B, C were created using Split case action. When this action is called on Case A, then I get IDs of B,C. If on B, then IDs of A, C and so on. We found Java Case API has nice method called fetchRelatedCases, which might work for us.
    • We must customize little bit split case logic, because it seems default Split case service flow do not clone document instances to newly created case, but only file existing instances into new folder, which is not wanted in our case. Again we think about using Java Case API to implement that.

    Now I would like to know some best practices or your experiences from larger projects about how to handle custom toolkit with service flows, which can have multiple JAR dependencies. For using Java CASE API, you need to include around 6 of them I guess in your classpath. So how would you structure your toolkit ?

    I am contemplating about these approaches:

    1. Create 1 external service JAR, which will have all dependencies bundled together. This might create one large JAR with about 20+ MBs, so it might slow or problematic when uploading to BAW server.
    2. Similar to point 1, but dependencies will be uploaded separately. I did some tests and for some reason invoking my service flows takes really long time, around 15 - 30 seconds (rough estimate). It looks like all server files are loaded into memory everytime flow is called.
    3. Created shared library on WAS, which will contain all necessary dependencies and link this library into BAW application. Here we are afraid it might collide with already loaded libraries by the core application and cause class loading issues.
    4. Create lightweight REST client as external service and all the logic will be implemented in separate web application hosted on WAS, exposed as REST services.
    5. Use Case REST or other JavaScript APIs/calls instead of Java variants, but here I have worries testing/debugging process might take much longer. Not to mention I would have to probably copy/paste some common methods to multiple places, which makes maintainability harder.

    What do you think ?

    Thanks for any info.

    Best regards,

    Ales



    ------------------------------
    Aleš Roszoha
    ------------------------------


  • 2.  RE: Custom toolkit with service flows, that have multiple JAR dependencies - best practices

    Posted Tue June 27, 2023 01:00 PM

    Develop custom code module, event action handler on case creation and update properties as required. Configure custom action to create folder of the case.



    ------------------------------
    Nitin Upasani
    ------------------------------



  • 3.  RE: Custom toolkit with service flows, that have multiple JAR dependencies - best practices

    Posted Wed June 28, 2023 06:04 AM

    I would create another process application, in which I would add the files. Lets call the application Case Helper API. In that application, after adding the .jar files, create an Exposed Automation Service, define its operations (for example, CloneDocuments(docid, destination)), create a ServiceFlow to call the JavaCode.

    And then from the original application, call the Case Helper API application with <SERVER>/automationservices/rest/CH_API/MyFancyAutomationService/MyFancyEndpoint.

    At the projects where i work, we have several helper applications that only serve as interfaces to services such as these, even acting as an Interface toward the natural API of BAW, since those API's often want Id's that are problematic instead of using Acronyms and servicenames to communcate.



    ------------------------------
    Johan Andersson
    ------------------------------