Topic
6 replies Latest Post - ‏2012-12-11T09:08:02Z by mmalc
Mahesh@123
Mahesh@123
3 Posts
ACCEPTED ANSWER

Pinned topic Fanout Primitive issue in IBM WESB v7.5

‏2012-08-20T15:24:21Z |
In IBM WESB v7.5, FanOut primitive in the iteration mode using XPath expression is always giving me last element in the array. How can I fire each element in the array?
Updated on 2012-12-11T09:08:02Z at 2012-12-11T09:08:02Z by mmalc
  • mmalc
    mmalc
    74 Posts
    ACCEPTED ANSWER

    Re: Fanout Primitive issue in IBM WESB v7.5

    ‏2012-10-07T09:13:15Z  in response to Mahesh@123
    Maybe you haven't specified something correctly as it works for me.

    What are you doing in the fan-out section? What clause do you have on the fan-in to end the loop?
    • mmalc
      mmalc
      74 Posts
      ACCEPTED ANSWER

      Re: Fanout Primitive issue in IBM WESB v7.5

      ‏2012-10-07T09:17:27Z  in response to mmalc
      Have a look at the samples in particular the "Aggregation by iteration" sample in the "Mediation features" section.
  • SystemAdmin
    SystemAdmin
    289 Posts
    ACCEPTED ANSWER

    Re: Fanout Primitive issue in IBM WESB v7.5

    ‏2012-10-26T22:21:37Z  in response to Mahesh@123
    This is a bug of BO maps. BO maps between FanOut-FanIn have it the FanIn context always the same value. Use the XSLT maps here instead, they work fine. (We use BO maps everywhere, but between FanOut-FanIn we use XSLT maps, because of this bug.)
    • mmalc
      mmalc
      74 Posts
      ACCEPTED ANSWER

      Re: Fanout Primitive issue in IBM WESB v7.5

      ‏2012-10-28T04:02:52Z  in response to SystemAdmin
      If using a BO Map is an issue in your Fan-Out flow then I'd raise a PMR rather than using an XSLT primitive. Each use of an XSLT primitive requires a serialize/deserialize from BO -> XML. OK if you have small payloads and low volumes but if you want to scale it up then every little bit adds on.

      The XSLT primitive is faster if you're transforming a request as soon as it gets into the flow, makes use of the deferred parsing mechanism. But if you're already in BO land then the BOMap is faster.
      • SystemAdmin
        SystemAdmin
        289 Posts
        ACCEPTED ANSWER

        Re: Fanout Primitive issue in IBM WESB v7.5

        ‏2012-10-28T20:05:56Z  in response to mmalc
        You're right, XSLT maps are slower (though I didn't know that there are situations when XSLT maps are faster). We've already submitted the PMR for this bug, I think. But:

        1. We have bad experience with IBM support, it takes a big effort to persuade them that there's a bug in their product. Even when we told them "you have this bug at this particular line of code in this particular class", they didn't act and fix that error. :-((

        2. WESB and IID are full of bugs. A fortnight or so ago I was asked to write down a list of bugs and problems we've met during the WESB development. I was able to put down about 50 of the more serious bugs (of the version 7.5), just by heart. And there is a lot more bugs I didn't recall at that time, and another lots of less serious bugs and problems. It would take a whole week to create a PMR for every of these bugs (with all the necessary details), and at least a month to persuade IBM to fix them. At that time our project would be over.

        Seriously and without exaggerating, WESB and IID is the most buggy development platform I've had to develop for. The idea is good, but the implementation is terrible. I would say they never tested it at IBM before releasing it. Shame on IBM.
        • mmalc
          mmalc
          74 Posts
          ACCEPTED ANSWER

          Re: Fanout Primitive issue in IBM WESB v7.5

          ‏2012-12-11T09:08:02Z  in response to SystemAdmin
          Just like there are best practices in building applications, there are unfortunately best practices for raising PMRs. In my line I come across a lot of people that have struggled with the PMR process and often we come in and help get the problem resolved reasonably quickly. For your information this is what I do when I have a re-creatable problem.

          1. Isolate the problem to the smallest possible set of components. Preferably without having to introduce your own systems in to the mix. For WID/IID, this is usually easy.
          2. Document in any document editor of your choosing, the steps needed to re-create the problem. This includes screenshots and itemised steps. This sounds like a lot but you need to do this anyway to prove to yourself that the problem is actualy with the product.
          3. When running the test, ensure the logs are empty before you start (or note the timestamp in the log files that you started/ended the test). (it's amazing that people think that sending multiple 50MB log files to someone to process with no pointers as to where to look will get the problem resolved faster)
          4. Gather the necessary files for the MustGather. (unfortunately this is just part of the process)
          5. Raise the PMR and send all the necessary info you've just collected. This will get you past Level 1 and give level 2 something to try immediately. If they are able to recreate your problem then it goes straight to Level 3 for resolution.

          It works for me and maybe next time it may work for you.