This discussion is archived
1 2 Previous Next 19 Replies Latest reply: Mar 13, 2008 5:31 AM by 3923 RSS

Please Publish Announced Workaround to Bpel Deployment Nightmare

575604 Newbie
Currently Being Moderated
Oracle's own Product Director and Senior Product Manager describe the horror in their document published on Oracle's own site Kevin Clugage and Robin Zimmermann.

http://www.oracle.com/technology/products/ias/bpel/pdf/bpel-admin-webinar.pdf

They put my feelings best where they show a photo of a guy trying to pull his hair out on the one of the "Deployment Challenge" slides.

I do not know why Oracle has chosen to break three very fundamental rules most anyone has ever had to work with:

1. Never put machine or deployment specific code in a source file
2. Never tell a user NOT to modify a file and then tell him to modify that same file if he wants to deploy.
3. Never publish a known horror, announce that there is a workaround, and not publish the workaround in great detail.

It is even more confusing why there isn't a huge outcry from customers. The only conclusion I can come to is there aren't enough customers to even care, I just don't know. Either way, I need guidance, as

They cite in this document the standard deployment situation for ANYTHING built in any normal situation. It is always expected to be built and deployed on at least these machines
* developerOne's machine
* developerTwo's machine
* developerThree's machine
* test server
* QA server
* production server

What I need is for Kevin Clugage and Robin Zimmermann to produce documentation for the workaround they published in the above document, and especially how to do it in a way that respects the instructions found in my wizard built files. (" DONOT EDIT THIS JDEV GENERATED FILE") I don't want to fix one problem and create another.

It would embarrass Oracle and my employer both if it were documented how much time we have wasted attempting to address this ridiculously simple issue over the past several months. Some reasonable urgency would be in order.
  • 1. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    322036 Employee ACE
    Currently Being Moderated
    user572601,
    we are sorry for the bad experience you seem to have with Oracle SOA Suite. I can try to help you overcome these issues reported below, but I need some help from you in specifying (maybe with a concrete example) what points you are concerned about.

    Based on my experience with the suite I have made some assumptions when answering the below questions from you

    1. Never put machine or deployment specific code in a source file
    2. Never tell a user NOT to modify a file and then tell him to modify that same file if he wants to deploy.
    3. Never publish a known horror, announce that there is a workaround, and not publish the workaround in great detail.


    To my understanding-
    question one refers to adding these computer names into build.xml (as shown on the mentioned slides, which you can safely move out to say build.dev.properties for the dev enviroment)

    In question two might refer to a stub generated by oracle webservice assembler (which would generate client code for a werbservice). I quickly scanned through a couple of bpel processes on my computer and have not found this entry somewhere else. While I agree, this is a generated stub based on a concrete wsdl, and there are many ways to "externalize" the endpoint (which is what I think you refer to)

    for question three - if you could point us to the location where this is mentioned, we will of course publish the workaround. This was surely not done by intend, so please take our apologizes.

    There is also a technote which explains deployment / test automation in SOA Suite - which can be found at http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/auto-deploy.html

    best regards
    clemens utschig - utschig
    oracle soa product mgmt
  • 2. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    575604 Newbie
    Currently Being Moderated
    Clemens:
    The lines below are directly from the reference document by Kevin Clugage and Robin Zimmermann. I need very specific instructions on how to accomplish this.

    [begin quote]
    Deployment in 10.1.3
    • Can consolidate all configuration properties in a BPEL project to bpel.xml
    • Can effectively tokenize configuration properties for deployment to multiple environments
    • Can use a single build.xml for development and deployment (for all developers and admins)
    • Uses standard Ant
    [end quote]

    In this same referenced document it quotes from many files which appear to be various source files by their content but are not identified. I can make assumptions but it is so hard to keep things running when you change generated files that I would rather not without very specific, complete, and tested instructions. We generally have to throw away any jdeveloper related bpel source file once it changes and start again from scratch, JDeveloper seems completely intolerant to any changes made to files that it did not make.

    The build.xml file on my files system created by JDeveloper 10.1.3.3.0 start with this comment "DONOT EDIT THIS JDEV GENERATED FILE." Kevin Clugage and Robin Zimmermann's document seem to contradict this but since it is quite high level and incomplete I couldn't say for sure.

    I have also been sent the below referenced document by different Oracle people, yourself included, but it does not address the workaround promised by Kevin Clugage and Robin Zimmermann in the above referenced document.
    http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/auto-deploy.html
  • 3. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    322036 Employee ACE
    Currently Being Moderated
    user572601,
    I took a quick look into Robin's (here referenced) slide deck ..

    He talks expicitely about the adapter wsdls (which are documented) and the bpel.xml to add these (changeable) properties.

    Concerning your point of
    "We generally have to throw away any jdeveloper related bpel source file once it changes and start again from scratch, JDeveloper seems completely intolerant to any changes made to files that it did not make."

    We recommend to change all properties through the visual bpel process editor - (e.g double click on the partnerlink, tab properties to add a property. The same procedure holds true for <configurations> and <preferences> within bpel.xml. I did file a bug a while ago on a sync issue between bpel.xml and the process definition itself (when you have the process open and edit the bpel.xml, and afterwards add something to the process).

    This will be addressed in a future release, and is now documented ("all properties should be changed/added through the visual editor").

    Unfortunately there are still some missing ones, eg. <activationAgents>. If you do modify them - pls make sure that you close the bpel process in the main window and the bpel.xml after you make these changes, and reopen the process again, this way, they should be in the cache.

    I have filed bug 6335788 - PROPERTIES FOR ACTIVATION AGENTS CANNOT BE CHANGED THROUGH UI for this.

    I agree that DONOT EDIT THIS JDEV GENERATED FILE is misleading - and filed a bug on this - 6335773 - BUILD.XML CONTAINS "DO NOT EDIT .." - WHILE <CUSTOMIZE> TASK MUST BE IN <BPELC>.

    We will try to address both of them in an upcoming patchset.

    Concerning the document (one of our regional directors did write ). This document represents what many of our enterprise customers do use every day to deploy/test their services/BPEL processes/ESB systems accross multiple platforms - most of them I have visited myself over the last 2 years.

    Please let me know if you ran accross other issues than the above mentioned ones, as we'd like to make sure that we address them in a future release (and/or patch).

    best regards
    clemens utschig
  • 4. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    575604 Newbie
    Currently Being Moderated
    Regarding your statement "This document represents what many of our enterprise customers do use every day to deploy/test their services/BPEL processes/ESB systems accross multiple platforms"

    So far all you have described is a reference to the source of my own question.

    Is there any more detailed documentation or am I just on my own ? I have not seen these documented anywhere, other than the place which I referenced above which provides the snippets, which raised my question in the first place.

    I am really doing a crappy job asking questions, because all I am getting back from anyone is defensive stuff, and no help.
  • 5. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    322036 Employee ACE
    Currently Being Moderated
    Looking into my email account what I have sent you - it is all the ant scripts, and property files to deploy / test the orderbooking (as referenced above), which is representative for a composite SOA application from a functional perspective, as it does contain almost everything that the Suite offers.

    As a reference - the complete documentation for <customize> can be found here (publicly)
    http://download.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/deployproc.htm#sthref3397
    which explains the usage, and contains samples (for partnerlink bindings).

    Concerning the white pieces within Robin's presentation (which seem to be from pdf'ing it) - here is the the missing content

    -- JNDI names, slide 14 --

    <oc4j-connector-factories>
    <connector-factory location="eis/DB/myConn" connector-name="Database Adapter">
    <config-property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
    <config-property name="connectionString" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
    <config-property name="userName" value="scott"/>
    <config-property name="password" value="tiger"/>
    ...

    -- THe deployment challenge, page 16 --

    <BPELSuitcase>
    <BPELProcess id="OrderBooking" src="OrderBooking.bpel">
    <partnerLinkBindings>
    <partnerLinkBinding name="CreditRatingService">
    <property name="wsdlLocation"> http://localhost:9700/orabpel/default/CreditRatingService/CreditRatingService?wsdl </property>
    </partnerLinkBinding>
    </partnerLinkBindings>
    <configurations>
    <property name="noAlterWSDL">true</property>
    <property name="sensorLocation">sensors.xml</property>
    <property name="xpathValidation">true</property>
    <property name="user">robin</property>
    <configurations>
    </BPELProcess>
    </BPELSuitcase>

    If you let us know what (specific) problems you run into, we will do our best to provide you guidance to eliminate these stones.

    best clemens
  • 6. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    441812 Newbie
    Currently Being Moderated
    it's not that you're asking bad questions - this seems to be how oracle works - i can say without reservation that their documentation is the worst i've ever seen. multitudes of contradictions, steps inferred but not explained. Their paid-for support is hardly better - i recently created a Service Request regarding some of the web services functionality on 10.1.3 and was quite disappointed with their support efforts. When they discovered that the problem was limited to windows, they suggested i switch to linux (rather than saying they'd work to resolve the bug). let's see.... change our entire development, testing, staging, and production environments over to linux. that's probably 15 servers. sure. i'll get right on that.

    I know this: if i didn't HAVE to use oracle middleware products i certainly wouldn't.
  • 7. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    322036 Employee ACE
    Currently Being Moderated
    Pete and Bryan,
    we are in the midst of repairing these contradictions, and improving documentation as well as its bundling and other things around it - and I am very sorry to hear about your bad experiences.

    We will try to help you to overcome these issues, and if they are bugs, support / we will file them and resolve them. The only thing we ask is to tell us - what does not work, and what you are trying to achieve (such as deploying a process with this and that, and trying to change JNDI names).

    If you want - you can reach me offline - clemens.utschig@oracle.com, and send me a list of things that you did not like, and things that we can do better in the future, to prevent you guys spending time on finding the right piece of doc (that is not contracting another one).

    We are humans too.

    best regards
    clemens utschig
    oracle SOA product mgmt.
  • 8. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    441812 Newbie
    Currently Being Moderated
    I understand that you guys are human, but at the same time you are charging significant sums of money for your products and what you deliver should be well documented and functional. If you were open-source I would have no complaints.

    I have provided documentation suggestions in other postings; here is another: write your documentation (esp. tutorials) from the viewpoint of someone who doesn't use JDeveloper. For example, describe the descriptor files and included parameters and the components that should be in an ear file for a particular example, rather than just saying something like "use JDev to deploy the application".

    Here's something from Web Services Manager: In the configuration for the Ldap Authenticate policy step, the default string for "LDAP adminDN" is listed as "ou=People,dc=corp,dc=oracle,dc=com" - exactly the same as for "LDAP baseDN".... is that right? It doesn't look right to me - seems like it should be an actual user, like "cn=orcladmin". So, I look at the Oracle Web Services Manager Administrator's Guide to see what it says and it says "This property is required when the LDAP admin login enabled property is set to true. The distinguished name for Admin. For example, cn=DirectoryManager." So..... should "LDAP adminDN" include only the lowest level of the directory (that is, the user part, as shown in the documentation), or should it include the whole directory as shown in the application user interface? My bet is that the default string in the application user interface was simply copied during development and never replaced with a valid value.

    Oh - and by the way - the statement "This property is required when the LDAP admin login enabled property is set to true" in the Oracle Web Services Manager Administrator's Guide (concerning "LDAP adminDN") is wrong: the value is required whether the "login enabled" property is set to true OR false (at least, the app won't let me save the policy without this value even if the "login enabled" property is set to false - it tells me "This is a required property and can not be left unassigned")..... is this a bug, or just incorrect documentation???? no one knows.
  • 9. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    441812 Newbie
    Currently Being Moderated
    a correction to the last paragraph of the previous post; should say:

    Oh - and by the way - the statement "This property is required when the LDAP admin login enabled property is set to true" in the Oracle Web Services Manager Administrator's Guide (concerning "LDAP adminDN") is misleading: the value is required whether the "login enabled" property is set to true OR false (at least, the app won't let me save the policy without this value even if the "login enabled" property is set to false - it tells me "This is a required property and can not be left unassigned")..... is this a bug, or just misleading documentation???? no one knows.
  • 10. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    322036 Employee ACE
    Currently Being Moderated
    Bryan,
    have you had support filing a doc bug on it (which would also bring clarification)? this way it would be directly feeded into the doc writing organization.. - and we would have a chance to track and fix these things right away.

    Given the 1000s of pages that we write for each release - we try to keep them as clean as possible, but unfortunately here and there a bug gets created, and only found post release.

    /clemens
  • 11. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    441812 Newbie
    Currently Being Moderated
    I don't know where the bug is! is it in the documentation or the application? If I set the the "LDAP admin login enabled" property to false, should the app still require that I give an adminDN? that seems like a bug to me.

    it's just messed up. Oracle's documentation is historically inaccurate enough that I don't ever know if the application is screwing up or the documentation is wrong - am I to create an SR for documentation and an SR for the application every time I find something that doesn't work as the documentation says it should?? I don't have time for that.

    regarding your statement "Given the 1000s of pages that we write for each release" I say this: stick to databases, which you know, and stay out of middleware. Then you'll have fewer things to keep track of.
  • 12. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    322036 Employee ACE
    Currently Being Moderated
    Ok - we got your point.
    Now let's go and make it better for the next release and get you an accurate answer. I have ping'ed the PM for OWSM - to get you an answer on your question - He should reply shortly (Vikas Jain, with whom you already seem to be in contact).

    It is only one TAR that I kindly ask you to open. The rest Oracle Support Services will figure out - and either file a doc bug, to amend the documentation and / or one on the product side. In any case it's just one. And if you provide some sort of writeup of steps you followed - it should be very easy for support to verify - and follow up on it.

    I don't know what happened that you are so frustrated with the SOA Suite, but it's in our best interest that we try to help you and maybe at some point change your mind. Taking this a step further - pls write up these things - and send them to me.

    best regards
    clemens utschig
  • 13. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    51151 Newbie
    Currently Being Moderated
    I have used this document to deploy my BPEL processes, and I didn't have to edit the build.xml.

    For every BPEL process that calls a partner link I create a pre-build.xml and a post-build.xml. These scripts are called by default. You will also need to have a properties file for every environment you want to deploy to.

    Here is an example of these files, please note these are specific to my environment by you will hopefully get an idea on how to achieve this.

    pre-build.xml

    <?xml version="1.0"?>
    <project name="bpel.pre-build" default="pre-build" basedir="./bpel">

    <property name="explicitErrorHandlerDeploy" value="http://${http.hostname}:{http.port}/orabpel/default/explicitErrorHandler/1.0/explicitErrorHandler?wsdl"/>

    <property name="ConvertVariablesDeploy" value="http://${http.hostname}:{http.port}/orabpel/default/ConvertVariables/ConvertVariables?wsdl"/>

    <property name="GetProfilesDeploy" value="http://${http.hostname}:{http.port}/orabpel/default/GetProfiles/1.0/GetProfiles?wsdl"/>

    <target name="pre-build">

    <bpelc input="${basedir}/bpel.xml" rev="${rev}" deploy="default" force="true">
    <customize>
    <partnerLinkBinding name="explicitErrorHandler">
    <property name="wsdlLocation">${explicitErrorHandlerDeploy}</property>
    </partnerLinkBinding>
    <partnerLinkBinding name="ConvertVariables">
    <property name="wsdlLocation">${ConvertVariablesDeploy}</property>
    </partnerLinkBinding>
    <partnerLinkBinding name="GetProfiles">
    <property name="wsdlLocation">${GetProfilesDeploy}</property>
    </partnerLinkBinding>
    </customize>
    </bpelc>
    <copy file="bpel.xml" tofile="bpel_orig.xml" overwrite="true"/>
    <copy file="_bpel.xml" tofile="bpel.xml" overwrite="true"/>
    </target>

    </project>

    post-build.xml

    <?xml version="1.0"?>
    <project name="bpel.post-build" default="post-build" basedir="./bpel">

    <target name="post-build">

    <echo>
    --------------------------------------------------------------
    | Copying bpel_orig.xml to bpel.xml
    --------------------------------------------------------------
    </echo>
    <copy file="bpel_orig.xml" tofile="bpel.xml" overwrite="true"/>
    </target>

    </project>

    properties file

    domain = default
    rev = 1.0
    admin.user = oc4jadmin
    admin.password = password
    http.hostname = server.domain
    http.port = 7777
    opmn.requestport = 6003
    oc4jinstancename = oc4j_soa

    Really the onlt thing that will change between BPEL processes is the pre-build.xml script, and this will be dependent on what partnerlink you are calling.

    Please remember when deploying you need to right-click the build.xml file and choose Run Ant. Before you press OK choose the properties file you want to use dependent on the environment you are deploying to. You do this by selecting the properties tab in the Run Ant (Bottom Box).

    Cheers
    James
  • 14. Re: Please Publish Announced Workaround to Bpel Deployment Nightmare
    554555 Newbie
    Currently Being Moderated
    Hi,

    Requiring "LDAP adminDN" when "LDAP admin login enabled" is set to false is a code bug. The workaround is to provide a dummy value for this configuration.

    As for the default value of the "LDAP adminDN" field, the default is incorrect. It should be modified to match with the administrator's dn for the directory.

    Thanks,
    Vikas Jain
    http://ws-security.blogspot.com
1 2 Previous Next