Hi Tomo

The BPELEngine interface, available from the RiftsawBPELExchangeHandler, has an untyped getManagementInterface() method that returns an object of type: org.apache.ode.bpel.pmapi.BpelManagementFacade.

This object implements the ProcessManagement API you are looking for.

Regards

Gary

Hi Tomo

Sorry I haven't dealt with that part of the code before. Jeff has more experience on the management side, so might know the answer.

Alternatively it may be worth posting some questions on the Apache ODE user forum?

Regards

Gary

Hi Tomo,

I am not sure you need to inject the switchyard property on getting the process property value. Because you've already used the mgmt API to store the correct property value (Injecting the SwitchYard's property value properly), there should be no need to inject them again on retrieving the value.

Any reasons you want to inject value on retrieving the value? Is it too late to inject the value on exchangeHandler? If it is too late, then we should do it on the time of deploying a process definition.

Regards

Jeff

Hey Jeff,

It's possible the property value could change during the lifecycle of the application.  I anticipate having the ability to change property values from the console.  That said, I don't know how changes to property values are handled by the AS runtime (e.g. system properties).  Depending on how changes are propagated, it might be possible to inject new values in response to notifications.

Best,

Rob

Hi Rob and Tomo,

Thanks for the clarification. Now it makes perfect sense to me, as I was thinking you had stored already the property, which now I guess were not true.

In terms of the evaluating the property, I am thinking that injecting values on the following method might be better :

BpelProcess.java

    public Node getProcessProperty(QName propertyName) {

        Node value = getEngine()._contexts.customProcessProperties.getProperty(propertyName);

        if (value != null) {

            return value;

        }

        Map<QName, Node> properties = _pconf.getProcessProperties();

        if (properties != null) {

            return properties.get(propertyName);

        }

        return null;

    }

The JaxpFunctionResolver$ProcessProperty will call the BpelRuntimeContext class, which in turn calls the BpelProcess.java::getProcessProperty method to resolve the properties.

As you can see the from the above code, it was looking for the properties in the customProcessProperty first, and then find it in the processConf, which stores the properties from the deploy.xml. I wasn't sure about how to get the properties from the SwitchYard, but if it requires the SwitchYard API, it may best that add an property in the bpel.properties, and then injecting/initialisation the class properly. In this case, the BPEL runtime doesn't need to depend on SwitchYard.

Hope this helps.

Jeff

BTW, I wasn't exactly sure the Management API's setProcessProperty works or not. When I was checking the code, it looks like to me that the ProcessConf only store the properties on the time of deploying ,and then expose them as an unmodified collection. The setProcessProperty was setting the properties directly into the database, but the ProcessConf only reads once on the time of deployment. So better to have a test case to validate it.

As to Rob's setting properties value on console, just double check that we just need to use the switchyard's facility to do so, because my above observation, please let me know if my observation was wrong.

Regards

Jeff

Hi Tomo,

I think you can use the similar way of the Bean service's implementation.

You can define a HashMap in the org.apache.ode.bpel.engine.Context class, and then inject the properties in the BPELComponent/BPELActivator when starts the BpelEngine. In the end, you'll need to update the BpelProcess::getProcessProperty(QName) method to include the logic of accessing the Context properties before acessing the builtin process configuration.

PS: When I said add an property entry in the bpel.properties, I meant to say add the SwitchYard context access class's full name, not the properties. :-). Anyway, I think we can use the approach that similars to the Bean Service property access.

Regards

Jeff

Hi Tomo

Just wondering whether an alternative approach to this would be to use the properties in the deploy.xml, and access them using the ode:process-property xpath function.

I know the aim of you task is to provide the properties from switchyard.xml, but there is a separate thread that will eventually result in the deploy.xml being generated from switchyard.xml. So indirectly your feature request could be satisfied using this generation approach and using the existing ODE supported process-property method?

Having said that, I just tried this process-property method and it didn't seem to work, so will have to investigate that further.

Regards

Gary