BPM, Workflow, and Case

BPM, Workflow, and Case

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

 View Only

  • 1.  Outbound Webservice

    Posted 03/18/20 02:34 PM
    Team,

    I would like to understand the best practices to implement the outbound web service. Is it good to use ' call webservice via soap' or better to add wsdl url and generate BO to call the method ?

    ------------------------------
    RK
    ------------------------------


  • 2.  RE: Outbound Webservice

    Posted 03/18/20 05:17 PM
    The "call web-service" item in the System Data Toolkit is an ancient approach that greatly predates the one that creates the BO from you based on the WSDL.  I would recommend following the generate BO path unless you have a reason it won't work for you.  I think the "call web service" item still exists because 

    1. There may still be some use cases the WSDL based one doesn't handle, so this gives you a route to another way to get there.
    2. There isn't (yet) a tool to move you from one to the other, so their isn't a "clean" way to deprecate the old one.
    3. The "call web-service" approach exists from before IBM acquired the product and many at IBM may not even know it exists.
    I believe you will get much better support, if you need it, following the more current approach.

    ------------------------------
    Andrew Paier
    ------------------------------



  • 3.  RE: Outbound Webservice

    Posted 03/18/20 11:13 PM
    Thank you Andrew for your explanation. I have a scenario where my existing application is using the 'call web service' method. When I tried to convert that it into latest approach, I found that output response BO has so many objects and list of objects in it. But I do not need that many information for my application.

    Where as in the existing approach, output comes as an XML element and parsing happens using XPATH. I feel the latest approach may cause the performance degrade due to the complex output BO from the provider. How to handle such scenario ?

    ------------------------------
    Rameshkumar Chandrasekar
    ------------------------------

    Original Message


  • 4.  RE: Outbound Webservice

    Posted 03/20/20 01:45 PM
    It is funny how often I see people saying "I don't want to use X because of performance.".  In my experience, most of the time when this is stated the following is true -
    1. No tests have been written to measure performance.
    2. No one is looking at the maintenance cost over time (which is generally much more expensive than more CPU power)
    3. No one has really looked at the load expected on the item in question.

    So if you are concerned about the performance of one vs. the other, I would suggest testing it and seeing how it does.  If you are doing your XPATH parsing using Javascript, that is actually pretty darn inefficient.  The IBM tool will be doing the work in Java instead.  Additionally, if there is a performance problem in IBM's code, you can ask them to make that better, whereas if there is problems in your code you have to do the work.

    Finally if the IBM call is not performant, what is the actual impact of this and how can we mitigate?  How often per day will this be called?  Is it user facing or back end?  Is there an opportunity to batch / cache / do something else that makes it feel quicker even though it isn't.


    ------------------------------
    Andrew Paier
    ------------------------------

    Original Message


  • 5.  RE: Outbound Webservice

    Posted 03/23/20 08:36 AM
    Thank you for your brief response. 

    Regards,
    Ramesh kumar
    BPM Consultant
    This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.


    ------Original Message------

    It is funny how often I see people saying "I don't want to use X because of performance.".  In my experience, most of the time when this is stated the following is true -
    1. No tests have been written to measure performance.
    2. No one is looking at the maintenance cost over time (which is generally much more expensive than more CPU power)
    3. No one has really looked at the load expected on the item in question.

    So if you are concerned about the performance of one vs. the other, I would suggest testing it and seeing how it does.  If you are doing your XPATH parsing using Javascript, that is actually pretty darn inefficient.  The IBM tool will be doing the work in Java instead.  Additionally, if there is a performance problem in IBM's code, you can ask them to make that better, whereas if there is problems in your code you have to do the work.

    Finally if the IBM call is not performant, what is the actual impact of this and how can we mitigate?  How often per day will this be called?  Is it user facing or back end?  Is there an opportunity to batch / cache / do something else that makes it feel quicker even though it isn't.


    ------------------------------
    Andrew Paier
    ------------------------------