Hi, I want to add some more information regarding this. Unified endpoint per each file is okey to go with as far as we do not need to edit configurations in any of the artifacts (deploy.xml, wsdl files, etc..) inside the BPEL package when deploying the same in different environments.
When we keep the .epr files outside the BPEL package we need to give the absolute path for each .epr inside the deploy.xml as AmilaM mentioned. And this is the limitation I see. Can this be achieved by passing a parameter to deploy.xml to get the path from a system property? * <invoke partnerLink="MultiplierPartnerLink">* * <service name="MultiplierService.wsdl:MultiplierService" port="MultiplierServiceSOAP11port_http">* * <endpoint xmlns="http://wso2.org/bps/bpel/endpoint/config"* * endpointReference=$xxxxx />* * </service>* * </invoke>* Thanks Thilini On Wed, Feb 15, 2012 at 8:52 AM, Thilini Ishaka <thil...@wso2.com> wrote: > > > On Wed, Feb 15, 2012 at 8:49 AM, Thilini Ishaka <thil...@wso2.com> wrote: > >> >> >> On Tue, Feb 14, 2012 at 9:54 PM, Keheliya Gallaba <kehel...@wso2.com>wrote: >> >>> Hi Thilini, >>> >>> I think currently we can have that functionality via unified endpoints. >>> You can refer to an external endpoint configuration in the deploy.xml like >>> the following: >>> >>> <invoke partnerLink="CreditRatingPL"> >>> <service name="crns:CreditRatingService" >>> port="CreditRatingPort"> >>> <endpoint xmlns=" >>> http://wso2.org/bps/bpel/endpoint/config"; >>> endpointReference="CreditRatingService.epr"/> >>> </service> >>> </invoke> >>> >>> That file can define an address like this: >>> >>> <wsa:EndpointReference >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xsi:schemaLocation="http://www.w3schools.com uep_schema.xsd" >>> xmlns:wsa="http://www.w3.org/2005/08/addressing"; >>> xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/";> >>> <wsa:Address>http://localhost:9000/services/CreditRatingService/ >>> </wsa:Address> >>> </wsa:EndpointReference> >>> >>> One restriction is you will have to define a config file for each >>> distinct invoke in a process. But the advantage is, when the environment >>> changes you can just change the file without changing the deployment >>> artifact. >>> >> Yes. That's true. But the initial thinking was to have a single config >> for each invocation. >> > I mean to avoid updating multiple configuration files. > > > >> >> Thanks >> Thilini >> >> >>> >>> Regards, >>> Keheliya >>> >>> >>> On Tue, Feb 14, 2012 at 9:38 PM, Paul Fremantle <p...@wso2.com> wrote: >>> >>>> Isn't this something that our endpoint unification is meant to take >>>> care of? >>>> >>>> Paul >>>> >>>> On 14 February 2012 15:16, Thilini Ishaka <thil...@wso2.com> wrote: >>>> >>>>> >>>>> Hi All, >>>>> >>>>> Consider a situation where we have multiple service (partner services) >>>>> invocations in a business process. >>>>> We need to change *soap:address location *for each and every wsdl >>>>> once a particular service uri is changed from x to y. This is a frequent >>>>> situation which we need one step solution. >>>>> I would suggest two approaches as; >>>>> >>>>> Have a single configuration file which lists *soap:address location *for >>>>> each wsdl (Then you only require to change the URIs inside the config >>>>> file); >>>>> 1. A script based solution. (perl/python) >>>>> 2. Write an own wsdl extension >>>>> >>>>> What would be the best solution here? >>>>> kindly appreciate your thoughts. >>>>> >>>>> Thanks >>>>> Thilini >>>>> >>>>> Regards >>>>> >>>>> Thilini Ishaka >>>>> WSO2 Inc >>>>> >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> Carbon-dev@wso2.org >>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Paul Fremantle >>>> CTO and Co-Founder, WSO2 >>>> OASIS WS-RX TC Co-chair, VP, Apache Synapse >>>> >>>> UK: +44 207 096 0336 >>>> US: +1 646 595 7614 >>>> >>>> blog: http://pzf.fremantle.org >>>> twitter.com/pzfreo >>>> p...@wso2.com >>>> >>>> wso2.com Lean Enterprise Middleware >>>> >>>> Disclaimer: This communication may contain privileged or other >>>> confidential information and is intended exclusively for the addressee/s. >>>> If you are not the intended recipient/s, or believe that you may have >>>> received this communication in error, please reply to the sender indicating >>>> that fact and delete the copy you received and in addition, you should not >>>> print, copy, retransmit, disseminate, or otherwise use the information >>>> contained in this communication. Internet communications cannot be >>>> guaranteed to be timely, secure, error or virus-free. The sender does not >>>> accept liability for any errors or omissions. >>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> Carbon-dev@wso2.org >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> >>> >>> >>> -- >>> *Keheliya Gallaba* >>> Software Engineer; >>> Integration Technologies Team; WSO2 Inc.; http://wso2.com, >>> *email: **keheliya [AT] wso2.com* <kehel...@wso2.com> >>> *mobile: +94 71 551 8881* >>> *blog: **http://galpotha.wordpress.com* <http://galpotha.wordpress.com>* >>> twitter: **http://twitter.com/keheliya* <http://twitter.com/keheliya>* >>> linked-in: >>> **http://lk.linkedin.com/in/keheliya*<http://lk.linkedin.com/in/keheliya> >>> >>> >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> Carbon-dev@wso2.org >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> Regards >> >> Thilini Ishaka >> WSO2 Inc >> >> > > > -- > Regards > > Thilini Ishaka > WSO2 Inc > > -- Regards Thilini Ishaka WSO2 Inc
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
