Topic
6 replies Latest Post - ‏2013-02-22T18:38:26Z by cbauch
cbauch
cbauch
3 Posts
ACCEPTED ANSWER

Pinned topic Working with previously defined xsd business data

‏2013-02-21T19:33:08Z |
I am working in BPM 8.0.1 Standard, and I have a couple of questions regarding defining Business Data objects and Web Services.

1. Is there a way to import previously created xsd schemas when defining Business Data?

In Advanced this is trivial, and it seems that, at least when consuming a Web Service, this is possible in Standard as well. I am not consuming a Web Service, but I am creating one in Process Designer that will kick off a BPD. The business objects have already been defined and are being used in production by other tools, such as Broker. If this is not possible, I think the only alternative is to place Broker flows in front of BPM that massage the data on the way in and out.

2. Is it possible to force a Web Service definition to honor Advanced Parameter Properties for Business Objects?

When defining a Web Service, Process Designer does not output schema that matches the internal schema for the Business Data objects. I have tried setting the "enable-advanced-parameter-properties-for-wsdl" property to true, but it still does not pick up things like "List Item Name" properties. The list items in the resulting WSDL are always named "item". This is related to the above question as I am attempting to define Business Data objects in a way that the incoming structure matches what the original schemas define (they just happen to have wrapped lists already).

  • Chris
Updated on 2013-02-22T18:38:26Z at 2013-02-22T18:38:26Z by cbauch
  • SystemAdmin
    SystemAdmin
    7615 Posts
    ACCEPTED ANSWER

    Re: Working with previously defined xsd business data

    ‏2013-02-21T20:19:35Z  in response to cbauch
    I think the short answer is that you really need to be using Advanced to do things like this.

    No, you can't import and XSD into Standard Edition. That feature has been asked for a long time. In my opinion, it's never been implemented because using pre-defined data types always ends up being a bad practice. Process data in PD should almost always be a small and simplified subset of system-of-record data types and any time I've seen people try to use canonical data types for process data types they have always deeply regretted that decision. If you choose to ignore this advice and want import a pre-existing XSD, you already have figured out the workaround: wrap the XSD in a WSDL wrapper and then introspect the WSDL to generate the types in PD.

    I'd give a similar answer to your question about exposed web services. Standard Edition (at least in my opinion) has a "we generate what we generate" approach to exposed WSDLs, and consuming systems must adapt to those generated WSDLs. Perhaps someone else has had a different experience, but my experience has been that if you want to have take the reverse approach of "here is the WSDL I want, let me back into generating the implementation for that WSDL" you really need to be working with IID and Advanced.

    I'm sympathetic that you "have what you have", but these are the exact kinds of use cases that Advanced Edition is designed for. In fact, I'd argue that in cases where you have an existing canonical data format that the best practice is to use Advanced Integration Services in ID to mediate those canonical formats into simplified formats for use in PD. That can both optimize for PD's execution and also aid in the ability for business analysts to understand and consume that data with PD.

    DAvid
    • cbauch
      cbauch
      3 Posts
      ACCEPTED ANSWER

      Re: Working with previously defined xsd business data

      ‏2013-02-22T13:24:38Z  in response to SystemAdmin
      I was afraid that this would be the answer. It's kind of disappointing because it makes the Standard product feel like it only exists to drive people to the Advanced version. How many Business Processes really exist that do not require much integration with other systems anyhow? Being able to understand xsd seems like such a basic requirement for a tool like this. As it stands, I can't really see using Standard for anything more than the simplest of human workflows.
      • bmruter
        bmruter
        40 Posts
        ACCEPTED ANSWER

        Re: Working with previously defined xsd business data

        ‏2013-02-22T13:40:30Z  in response to cbauch
        Interesting comment. As a long time WPS customer we keep thinking why would anyone want to add standard to their portfolio just to get coaches (although we are investigating some of these features). WPS (BPM Advanced) already has a solid human task manager component. Hopefully IBM will get to a single unified product offering someday instead of having two very different development models in the product. Also there is not a whole lot of guidance on when each one is appropriate.
        • SystemAdmin
          SystemAdmin
          7615 Posts
          ACCEPTED ANSWER

          Re: Working with previously defined xsd business data

          ‏2013-02-22T16:38:31Z  in response to bmruter
          So, for those of you who don't know me in person, I've been working with BPM since 2005. I wrote for eBizQ for a while, and worked for Fuego, BEA, Lombardi, and IBM in varies capacities related to BPM. And I find this conversation fascinating, because I've heard so many different versions of it over the years. The following is all my opinion, of course, but its an opinion that comes from many years of experience and working for a lot of companies and clients with a lot of different perspective.

          So, my answers to some of the questions raised in this thread:

          • How many Business Processes really exist that do not require much integration with other systems anyhow? This is a very interesting question. Because many people (including me) believe that there is a large untapped market out there for business processes that are "simple" and require no integration or trivial integration. It is amazing how much of the world is operated with email and spreadsheets. There is a huge market for trying to improve these processes. But I don't think that was the real question being asked here. I think the real question being asked is:

          • How many Business Processes that people are trying to solve with BPM require more integration capabilities than existing in IBM BPM Standard? I know that you may disagree with me on this, but my experience has been very, very few. In all of the years of working with BPM I never ran into a real world customer with a business problem that I couldn't address because of the integration capabilities of Standard Edition. (There are a couple of cases where some third party connectors/libraries have been needed, but none where it just wouldn't be possible.) Sometimes the solution wasn't as elegant as I would have liked, but I was always able to address the core elements of the business problem. And while I know there are some use cases out there where that isn't true, I think we will see fewer and fewer of them over time, as ESBs end up doing more of the heavy integration work.

          • Implied in that question is "How much of the integration work should the BPM layer be responsible for?". My general answer here is "As little as possible". Business Process Management is about the business. There are going to be times that the BPM layer is going to have to step up and do some integration work to make a process work, but the more we can push that integration into a separate EAI or ESB tier, the cleaner the process will be and the more "business friendly" the processes will be. I think canonical data formats fit into this category, for the reasons I mentioned my previous comment.

          • "As a long time WPS customer we keep thinking why would anyone want to add standard to their portfolio just to get coaches (although we are investigating some of these features)?" It's always interesting to me to hear some of these comments. Because when I first encountered WPS many years ago, my reaction was "it has no repository component", "it has no governance capabilities", "its native forms can barely handle prototyping", "it requires an external tool for analytics", "its round tripping features are extremely limited and fragile", "its versioning capabilities are limited and very technical", "the ease of use of even its 'business friendly' modeler is extremely lacking', "there's no process improvement or optimization capabilities". In short, WPS didn't have 90% of the features that I considered basic BPM functionality. Obviously, it had its strengths, but it was a very different animal than every other BPM tool that I had worked with. Ironically, I had had the same reaction to WPS that bmruter had to Standard Edition: I wouldn't use it for anything other than the most trivial processes. Because the lack of any kind of governance, round tripping, change management, and business friendly tools meant that if you couldn't get it right in version 1.0, you basically were never going to get it right. So, if I were in bmruter shoes, I wouldn't be looking at Standard Edition because of the coach functionality. (Frankly, I think it's clear from this forum that the "new coaches" are still undergoing a lot of growing pains and the legacy coaches were great for their time but becoming quite dated in architecture.) I would instead be looking at Standard Edition for the Process Center, playbacks, and for how the Standard Edition architecture can drive a different relationship between business and IT.

          Let me also make a few general observations. Firstly, there are a lot of different views about BPM. I know that different people have different opinions about what what is critical for a BPM product. (Which is why I find WPS users so fascinating, as their opinions on what is critical are so different than mine.) But I think that cbauch's comment that "It's kind of disappointing because it makes the Standard product feel like it only exists to drive people to the Advanced version." is definitely untrue. I'd say that vast majority of IBM BPM customers are not utilizing ID or the Advanced features. If you look at this forum, how many of the questions are about the Advanced-only features? Very few. So I certainly wouldn't accuse IBM of having Standard Edition out there just to upsell to Advanced. In fact, if I'd accuse IBM of not being very good about communicating the added value of Advanced Edition. Which, unfortunately leads to situations like this where someone really could benefit from the added features, but for some reason chose not to license them.

          I don't want to sound like a cheerleader here, but the integration between "Lombardi" and "WPS" has been pretty amazing to me. It's maybe a little complex, but you have a huge array of tools available to use and virtually any use case can be addressed. Want to take an integration-oriented approach and start with the XSD/WSDL? You can do that. Want process governance and industry-leading business-focused features? You have that. Want to communicate between a business-oriented BPMN process and an IT oriented mediation or BPEL flow? It's point and click. More or less, we've ended up in a world with the best of breed from both products. Compare that to Oracle, where you can summarize it as three years of trying to integrate their two products after which they just gave up and abandoned one of them. Or TIBCO, where you can summarize it as four years of trying to integrate two products, after which they gave up and abandoned both of the them. Or Metastorm, where they basically haven't even tried to integrate any of the five products they've ended up with. (With the possible exception of Proforma and that hasn't gone very well from what I've heard.)

          I'd love to see some more simplification in the product (especially around install), but I actually think I'm coming to like the "two model" approach. It ends up being a pretty clean line between process-focused components and integration-focused components.

          Sorry for getting up on the soapbox. I recognize that the original poster really just wanted to get something done, and now faces an obstacle to accomplishing that. So my opinions about the separation of integration and process may not be comforting. Apologies for that, and all I can do is tell you that IBM does have some documents internally that can help you justify the value add of Advanced Edition. (If you need help in finding those documents send me an email and I'll send you some names of people I know.)

          David
          • jmac_EmeriCon
            jmac_EmeriCon
            277 Posts
            ACCEPTED ANSWER

            Re: Working with previously defined xsd business data

            ‏2013-02-22T17:24:38Z  in response to SystemAdmin
            David:

            Great discussion.

            My background is all IBM workflow products, I started working with FlowMark in 1994 and have worked extensively with all IBM workflow products (bar Server Foundation) since.

            Regarding why you would want to use IBPM Standard (i.e. WLE, or what I call the BPMN engine) I would like to emphasize that the playback capability alone makes this tool worth it. The collaboration with the business available through the playback gives better collaboration than any of the previous IBM tools (personal opinion). Continuous collaboration with the process owners (i.e. the business) is the key to successful workflow implementations.

            Regards

            John


            _______________________________________________________________________

            John McDonald

            EmeriCon, LLC
          • cbauch
            cbauch
            3 Posts
            ACCEPTED ANSWER

            Re: Working with previously defined xsd business data

            ‏2013-02-22T18:38:26Z  in response to SystemAdmin
            I feel like IBM needs to push use of the two model approach a little more though. I do agree that each side has its own complimentary strengths and weaknesses, and IBM has also done a very good job integrating the two products.

            What I have noticed though is that people familiar with WebSphere Process Server prefer only those capabilities in Advanced. From your comment, it seems the inverse is true as well, with people familiar with the Lombardi way of doing things more comfortable there. There is still enough overlap between the two products that it isn't obvious when to jump from one to the other. The result seems to be that solutions stay in only one half of the tool. The existence of a Standard edition doesn't really help this issue either as it only highlights the fact that there are two separate products here.