You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com> on 2008/04/28 11:50:24 UTC
Logging from BPEL script
Hi
Is there any possibility to log some information from BPEL script?
I think about some additional activity. Probably there isn't such
activity but as I know there is possibility to implement and add own
activity to BPEL.
How can I add new activity to ODE? Is there any description how to do
that?
--
Regards
Mateusz Nowakowski
Re: Group activity ?
Posted by Alex Boisvert <bo...@intalio.com>.
This isn't possible in BPEL 2.0 without using a separate process to hold the
common code, which is probably too heavy-weight.
A lightweight approach might be to create C-like macros and use a
preprocessor to transform your BPEL prior to deployment. XSLT comes to mind
for the implementation.
alex
On Tue, May 6, 2008 at 8:21 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> Is this possible to group activities and use such instruction groups
> several times? I think about something similar to procedure of function
> in any programming language.
>
> I have a piece of BPEL script and I need to insert it in to all my
> global <faultHandlers> catch elements.
> I'd like to reuse my own code.
>
> I cannot solve it by rethrowing faults, because I'm on the top of fault
> handlers.
>
> --
> Regards
> Mateusz Nowakowski
>
Group activity ?
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
Is this possible to group activities and use such instruction groups
several times? I think about something similar to procedure of function
in any programming language.
I have a piece of BPEL script and I need to insert it in to all my
global <faultHandlers> catch elements.
I'd like to reuse my own code.
I cannot solve it by rethrowing faults, because I'm on the top of fault
handlers.
--
Regards
Mateusz Nowakowski
Re: ODE Maven artifacts
Posted by Matthieu Riou <ma...@offthelip.org>.
On Tue, May 13, 2008 at 11:16 AM, Matthieu Riou <ma...@offthelip.org>
wrote:
> On Tue, May 13, 2008 at 2:01 AM, Nowakowski, Mateusz <
> Mateusz.Nowakowski@sabre-holdings.com> wrote:
>
> > Hi all,
> >
> > I cannot find ODE Maven artifacts for version 1.1.1
> >
> > I assume it should be under
> > http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ode
> > /
> > but there are only artifacts for version 1.1
> >
>
> Mmmh seems that I forgot to mirror them, sorry about that. I'll do it now,
> in the meantime you can use:
>
> http://people.apache.org/~mriou/ode-1.1.1/<http://people.apache.org/%7Emriou/ode-1.1.1/>
>
> They should be propagated tomorrow in the various Maven repositories.
>
Actually they seem to be published live on people.apache.org so you can
already get them on:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ode/
Cheers,
Matthieu
>
> Cheers,
> Matthieu
>
>
> >
> > --
> > Regards
> > Mateusz Nowakowski
> >
>
>
RE: ODE Maven artifacts
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
Thanks, I've handled the issue the same way. I've inserted projects into
my own maven repository.
--
Regards
Mateusz Nowakowski
-----Original Message-----
From: matthieu.riou@gmail.com [mailto:matthieu.riou@gmail.com] On Behalf
Of Matthieu Riou
Sent: Tuesday, May 13, 2008 8:16 PM
To: user@ode.apache.org
Subject: Re: ODE Maven artifacts
On Tue, May 13, 2008 at 2:01 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> Hi all,
>
> I cannot find ODE Maven artifacts for version 1.1.1
>
> I assume it should be under
>
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ode
> /
> but there are only artifacts for version 1.1
>
Mmmh seems that I forgot to mirror them, sorry about that. I'll do it
now,
in the meantime you can use:
http://people.apache.org/~mriou/ode-1.1.1/
They should be propagated tomorrow in the various Maven repositories.
Cheers,
Matthieu
>
> --
> Regards
> Mateusz Nowakowski
>
Re: ODE Maven artifacts
Posted by Matthieu Riou <ma...@offthelip.org>.
On Tue, May 13, 2008 at 2:01 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> Hi all,
>
> I cannot find ODE Maven artifacts for version 1.1.1
>
> I assume it should be under
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ode
> /
> but there are only artifacts for version 1.1
>
Mmmh seems that I forgot to mirror them, sorry about that. I'll do it now,
in the meantime you can use:
http://people.apache.org/~mriou/ode-1.1.1/
They should be propagated tomorrow in the various Maven repositories.
Cheers,
Matthieu
>
> --
> Regards
> Mateusz Nowakowski
>
ODE Maven artifacts
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
Hi all,
I cannot find ODE Maven artifacts for version 1.1.1
I assume it should be under
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ode
/
but there are only artifacts for version 1.1
--
Regards
Mateusz Nowakowski
Re: Logging from BPEL script
Posted by Alex Boisvert <bo...@intalio.com>.
Ok, I understand the issue now. Thanks for the explanation.
This, ahem, idiosyncrasy, is actually defined by the BPEL 2.0 spec in
section 8.4.2 (Replacement Logic of Copy Operations). When you're copying
from one element (EII) to another element (EII), you can specify the
"keepSrcElementName" attribute to define the behavior you want.
To paraphrase the spec,
- When the keepSrcElementName attribute is set to "no" (which is the
default), the target element name is maintained
- When the keepSrcElementName attribute is set to "yes", the source
element name is used as the name of the resulting destination element.
It sounds like you'd want to set "keepSrcElementName" to "yes" in your case.
I think you put your finger on it earlier, though, the real issue here is
the lack of schema validation that makes some of these errors go by
silently.
alex
On Tue, May 13, 2008 at 1:50 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> Thank you for your answer.
> It gives me more lights on the problem.
>
> >I'm not sure about the "merge" issue that you mention. Can you provide
> >more detail?
>
> For example I have variable defined that way:
>
> <bpel:variable name="someVariable" element="tns:SomeElement"/>
>
> And an example of tns:SomeElement element type looks like :
>
> <SomeElement xmlns="....">
> <AnotherSomeTag>......</AnotherSomeTag>
> </SomeElement>
>
> When I tied to assign something like this:
>
> <TotallyDifferentType xmlns="...." someAttr="...">
> <xx>lorem ipsum</xx>
> <yyy>some content</yyy>
> </TotallyDifferentType>
>
> to variable someVariable
> the result is:
>
> <SomeElement xmlns="...." someAttr="...">
> <xx>lorem ipsum</xx>
> <yyy>some content</yyy>
> </SomeElement>
>
> This is done silently of course.
>
>
> --
> Regards
> Mateusz Nowakowski
> -----Original Message-----
> From: Alex Boisvert [mailto:boisvert@intalio.com]
> Sent: Monday, May 12, 2008 11:58 PM
> To: user@ode.apache.org
> Subject: Re: Logging from BPEL script
>
> Hi Mateusz,
>
> I'm coming back to this thread after a busy week at
> CommunityOne/JavaOne,
> Scala Lift-Off, and all that craziness...
>
> On Wed, May 7, 2008 at 1:51 AM, Nowakowski, Mateusz <
> Mateusz.Nowakowski@sabre-holdings.com> wrote:
>
> > >I would be interested in hearing more about these. What are your top
> > >itches?
> >
> > - BPEL is not completely programming language. It doesn't contain
> > something like procedure or function instruction. It is also
> impossible
> > to share code between processes. Only copy-paste methodology works.
>
>
> Correct. There's been a few proposals/experiments in the past but I
> haven't
> heard anything recently about these efforst.
>
> e.g.
> https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid
> /7d26a4e1-0601-0010-b9a4-c815157e69af<https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7d26a4e1-0601-0010-b9a4-c815157e69af>
> http://www.ibm.com/developerworks/library/specification/ws-bpelsubproc/
>
> - ServiceMix integration. A last problem with deploying ODE within SM is
> > minor in my opinion. ODE slightly doesn't fit to SM. When message
> > arrives to ODE from SM, it looses all normalized messages properties
> > (there was a short discussion about it) - so if we have something in
> > properties we need to make hardcore workaround and copies properties
> > into xml payload. It breaks service schema, but it doesn't matter for
> > ODE.
>
>
> Generally speaking, BPEL wasn't designed to support low-level message
> properties or protocol details, whether they are JBI-specific, or come
> from
> WS-Addressing headers, etc. This is the kind of details that's better
> left hidden from the business process to make the process as reusable
> and
> portable as possible.
>
> This being said, there have been a few ideas thrown around to supporting
> some of these in Apache Ode. We've had some recent discussions within
> Intalio and Matthieu should post some proposal about this on the mailing
> list for wider discussion.
>
>
> > - Schema validation. It is written in the documentation that schema
> > validation is not implemented. It is not completely true. When you
> > assign some data to variable, ODE checks the first tag of data. A very
> > strange thing appears when you assign completely different data to
> > inappropriate variable type. ODE silently "merges" input data with
> > destination variable type that the result has the first tag the same
> as
> > destination type, but payload is from input data...
>
>
> Ode attempts to be very JBI compliant and follow the normalization rules
> defined by the JBI spec; we didn't define our own rules. The only
> message
> converters we have (to complement the standard JBI one) were written to
> support existing ServiceMix components that didn't follow JBI rules.
>
> This being said, I think this is an area were much improvements can be
> done. Right now Ode supports only one message converter at a time.
> This is
> inconvenient if you have both standard and non-standard components in
> your
> architecture. We should probably support more than one at a time and
> dynamically select the most appropriate one at runtime. Second, the
> error
> handling and error reporting could be improved to provide more
> visibility
> into how messages are matched, mapped or converted into and out of Ode.
> The current behavior is rather silent and thus doesn't provide much clue
> as
> to why messages are not processed when they don't fit the expected
> format.
>
> I'm not sure about the "merge" issue that you mention. Can you provide
> more
> detail?
>
> - Last my JIRA entry ODE-263. onAlarm is not working. It generates alarm
> > only after completed activity, not after specified amount of time. In
> > other words it doesn't work. We want use this functionality as a
> timeout
> > guard, but because of that we need to implement this functionality
> > outside ODE.
>
>
> Ok, I'll take a look.
>
>
> > - Some useful extensions like external variables or adding own
> > activities are not in stable ODE version. We cannot rely on trunk.
> > Faster releases would be appropriate.
>
>
> Actually, external variables are on the Ode 1.1 branch and will be part
> of
> the next stable 1.2 release.
>
> Things that are on the trunk but not in 1.1 are,
> -Atomic scopes (transactions)
> -BPEL extension activities (including Javascript E4X assigns)
> -Improvement to the IL messaging interaction model
> (future support for reliable messaging, transactional invoke, better
> async
> handling, ...)
>
> The main issue preventing us from migrating to and releasing the trunk
> is
> backward compatibility. Maciej was working on dual support for both Ode
> 1.1-compiled processes and Ode-trunk compiled processes but it's taken
> longer than expected and he's been less available than expected. We're
> waiting for him to clean up and commit what he's done so far so we can
> take
> it from there.
>
> alex
>
RE: Logging from BPEL script
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
Thank you for your answer.
It gives me more lights on the problem.
>I'm not sure about the "merge" issue that you mention. Can you provide
>more detail?
For example I have variable defined that way:
<bpel:variable name="someVariable" element="tns:SomeElement"/>
And an example of tns:SomeElement element type looks like :
<SomeElement xmlns="....">
<AnotherSomeTag>......</AnotherSomeTag>
</SomeElement>
When I tied to assign something like this:
<TotallyDifferentType xmlns="...." someAttr="...">
<xx>lorem ipsum</xx>
<yyy>some content</yyy>
</TotallyDifferentType>
to variable someVariable
the result is:
<SomeElement xmlns="...." someAttr="...">
<xx>lorem ipsum</xx>
<yyy>some content</yyy>
</SomeElement>
This is done silently of course.
--
Regards
Mateusz Nowakowski
-----Original Message-----
From: Alex Boisvert [mailto:boisvert@intalio.com]
Sent: Monday, May 12, 2008 11:58 PM
To: user@ode.apache.org
Subject: Re: Logging from BPEL script
Hi Mateusz,
I'm coming back to this thread after a busy week at
CommunityOne/JavaOne,
Scala Lift-Off, and all that craziness...
On Wed, May 7, 2008 at 1:51 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> >I would be interested in hearing more about these. What are your top
> >itches?
>
> - BPEL is not completely programming language. It doesn't contain
> something like procedure or function instruction. It is also
impossible
> to share code between processes. Only copy-paste methodology works.
Correct. There's been a few proposals/experiments in the past but I
haven't
heard anything recently about these efforst.
e.g.
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid
/7d26a4e1-0601-0010-b9a4-c815157e69af
http://www.ibm.com/developerworks/library/specification/ws-bpelsubproc/
- ServiceMix integration. A last problem with deploying ODE within SM is
> minor in my opinion. ODE slightly doesn't fit to SM. When message
> arrives to ODE from SM, it looses all normalized messages properties
> (there was a short discussion about it) - so if we have something in
> properties we need to make hardcore workaround and copies properties
> into xml payload. It breaks service schema, but it doesn't matter for
> ODE.
Generally speaking, BPEL wasn't designed to support low-level message
properties or protocol details, whether they are JBI-specific, or come
from
WS-Addressing headers, etc. This is the kind of details that's better
left hidden from the business process to make the process as reusable
and
portable as possible.
This being said, there have been a few ideas thrown around to supporting
some of these in Apache Ode. We've had some recent discussions within
Intalio and Matthieu should post some proposal about this on the mailing
list for wider discussion.
> - Schema validation. It is written in the documentation that schema
> validation is not implemented. It is not completely true. When you
> assign some data to variable, ODE checks the first tag of data. A very
> strange thing appears when you assign completely different data to
> inappropriate variable type. ODE silently "merges" input data with
> destination variable type that the result has the first tag the same
as
> destination type, but payload is from input data...
Ode attempts to be very JBI compliant and follow the normalization rules
defined by the JBI spec; we didn't define our own rules. The only
message
converters we have (to complement the standard JBI one) were written to
support existing ServiceMix components that didn't follow JBI rules.
This being said, I think this is an area were much improvements can be
done. Right now Ode supports only one message converter at a time.
This is
inconvenient if you have both standard and non-standard components in
your
architecture. We should probably support more than one at a time and
dynamically select the most appropriate one at runtime. Second, the
error
handling and error reporting could be improved to provide more
visibility
into how messages are matched, mapped or converted into and out of Ode.
The current behavior is rather silent and thus doesn't provide much clue
as
to why messages are not processed when they don't fit the expected
format.
I'm not sure about the "merge" issue that you mention. Can you provide
more
detail?
- Last my JIRA entry ODE-263. onAlarm is not working. It generates alarm
> only after completed activity, not after specified amount of time. In
> other words it doesn't work. We want use this functionality as a
timeout
> guard, but because of that we need to implement this functionality
> outside ODE.
Ok, I'll take a look.
> - Some useful extensions like external variables or adding own
> activities are not in stable ODE version. We cannot rely on trunk.
> Faster releases would be appropriate.
Actually, external variables are on the Ode 1.1 branch and will be part
of
the next stable 1.2 release.
Things that are on the trunk but not in 1.1 are,
-Atomic scopes (transactions)
-BPEL extension activities (including Javascript E4X assigns)
-Improvement to the IL messaging interaction model
(future support for reliable messaging, transactional invoke, better
async
handling, ...)
The main issue preventing us from migrating to and releasing the trunk
is
backward compatibility. Maciej was working on dual support for both Ode
1.1-compiled processes and Ode-trunk compiled processes but it's taken
longer than expected and he's been less available than expected. We're
waiting for him to clean up and commit what he's done so far so we can
take
it from there.
alex
Re: Logging from BPEL script
Posted by Alex Boisvert <bo...@intalio.com>.
Hi Mateusz,
I'm coming back to this thread after a busy week at CommunityOne/JavaOne,
Scala Lift-Off, and all that craziness...
On Wed, May 7, 2008 at 1:51 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> >I would be interested in hearing more about these. What are your top
> >itches?
>
> - BPEL is not completely programming language. It doesn't contain
> something like procedure or function instruction. It is also impossible
> to share code between processes. Only copy-paste methodology works.
Correct. There's been a few proposals/experiments in the past but I haven't
heard anything recently about these efforst.
e.g.
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7d26a4e1-0601-0010-b9a4-c815157e69af
http://www.ibm.com/developerworks/library/specification/ws-bpelsubproc/
- ServiceMix integration. A last problem with deploying ODE within SM is
> minor in my opinion. ODE slightly doesn't fit to SM. When message
> arrives to ODE from SM, it looses all normalized messages properties
> (there was a short discussion about it) - so if we have something in
> properties we need to make hardcore workaround and copies properties
> into xml payload. It breaks service schema, but it doesn't matter for
> ODE.
Generally speaking, BPEL wasn't designed to support low-level message
properties or protocol details, whether they are JBI-specific, or come from
WS-Addressing headers, etc. This is the kind of details that's better
left hidden from the business process to make the process as reusable and
portable as possible.
This being said, there have been a few ideas thrown around to supporting
some of these in Apache Ode. We've had some recent discussions within
Intalio and Matthieu should post some proposal about this on the mailing
list for wider discussion.
> - Schema validation. It is written in the documentation that schema
> validation is not implemented. It is not completely true. When you
> assign some data to variable, ODE checks the first tag of data. A very
> strange thing appears when you assign completely different data to
> inappropriate variable type. ODE silently "merges" input data with
> destination variable type that the result has the first tag the same as
> destination type, but payload is from input data...
Ode attempts to be very JBI compliant and follow the normalization rules
defined by the JBI spec; we didn't define our own rules. The only message
converters we have (to complement the standard JBI one) were written to
support existing ServiceMix components that didn't follow JBI rules.
This being said, I think this is an area were much improvements can be
done. Right now Ode supports only one message converter at a time. This is
inconvenient if you have both standard and non-standard components in your
architecture. We should probably support more than one at a time and
dynamically select the most appropriate one at runtime. Second, the error
handling and error reporting could be improved to provide more visibility
into how messages are matched, mapped or converted into and out of Ode.
The current behavior is rather silent and thus doesn't provide much clue as
to why messages are not processed when they don't fit the expected format.
I'm not sure about the "merge" issue that you mention. Can you provide more
detail?
- Last my JIRA entry ODE-263. onAlarm is not working. It generates alarm
> only after completed activity, not after specified amount of time. In
> other words it doesn't work. We want use this functionality as a timeout
> guard, but because of that we need to implement this functionality
> outside ODE.
Ok, I'll take a look.
> - Some useful extensions like external variables or adding own
> activities are not in stable ODE version. We cannot rely on trunk.
> Faster releases would be appropriate.
Actually, external variables are on the Ode 1.1 branch and will be part of
the next stable 1.2 release.
Things that are on the trunk but not in 1.1 are,
-Atomic scopes (transactions)
-BPEL extension activities (including Javascript E4X assigns)
-Improvement to the IL messaging interaction model
(future support for reliable messaging, transactional invoke, better async
handling, ...)
The main issue preventing us from migrating to and releasing the trunk is
backward compatibility. Maciej was working on dual support for both Ode
1.1-compiled processes and Ode-trunk compiled processes but it's taken
longer than expected and he's been less available than expected. We're
waiting for him to clean up and commit what he's done so far so we can take
it from there.
alex
Re: Logging from BPEL script
Posted by Wayne Keenan <wa...@gmail.com>.
Hi,
On Wed, May 7, 2008 at 9:51 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:
> >> Thank you
> >>
> >> I've also think about this workaround... but we didn't decide to do
> that
> >> way, because it is too complicated and resource consuming... logging
> >should
> >> be as fast as possible...
> >> I think that log activity should be present in the standard, but the
> >> behavior should depend on the implementation.
> >
> >
> >Have you considered using the events that Ode generates?
>
> Yes, we are using ODE event listeners, but these are not perfect. We'd
> like for example to log current state of all variables. The EventContext
> is deprecated, but potentially gives possibility to do that. It is
> deprecated, because it is not working for only in memory processes
> (there was a discussion some time ago about it)
>
> >> BPEL/ODE is annoying me slowly... It is very difficult to do very
> easy
> >> things and we need to discover very ugly workarounds to make things
> work
> >
> >
> >I would be interested in hearing more about these. What are your top
> >itches?
>
> - BPEL is not completely programming language. It doesn't contain
> something like procedure or function instruction. It is also impossible
> to share code between processes. Only copy-paste methodology works.
<snip>
Although I'm new to BPEL and ODE, that statement regarding sharing code is
completely correct, as there are
Abstract Process, so although not reuse by composition, does promote reuse
by inheritance.
As far a procedural/function calling goes, an 'invoke' to a BPEL process
hosted/advertised by the same
ODE instance as the caller would be a likely candidate for in-[Java|BPEL]VM
optimisation, not that such a thing
exists at the moment. Although is the declarative overhead of the partner
link make it worth implementing some kind of <invoke-local-operation>
extension.
Regards
Wayne
RE: Logging from BPEL script
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
>> Thank you
>>
>> I've also think about this workaround... but we didn't decide to do
that
>> way, because it is too complicated and resource consuming... logging
>should
>> be as fast as possible...
>> I think that log activity should be present in the standard, but the
>> behavior should depend on the implementation.
>
>
>Have you considered using the events that Ode generates?
Yes, we are using ODE event listeners, but these are not perfect. We'd
like for example to log current state of all variables. The EventContext
is deprecated, but potentially gives possibility to do that. It is
deprecated, because it is not working for only in memory processes
(there was a discussion some time ago about it)
>> BPEL/ODE is annoying me slowly... It is very difficult to do very
easy
>> things and we need to discover very ugly workarounds to make things
work
>
>
>I would be interested in hearing more about these. What are your top
>itches?
- BPEL is not completely programming language. It doesn't contain
something like procedure or function instruction. It is also impossible
to share code between processes. Only copy-paste methodology works.
- ServiceMix integration. A last problem with deploying ODE within SM is
minor in my opinion. ODE slightly doesn't fit to SM. When message
arrives to ODE from SM, it looses all normalized messages properties
(there was a short discussion about it) - so if we have something in
properties we need to make hardcore workaround and copies properties
into xml payload. It breaks service schema, but it doesn't matter for
ODE. ODE has very unique schema validation (next point).
- Schema validation. It is written in the documentation that schema
validation is not implemented. It is not completely true. When you
assign some data to variable, ODE checks the first tag of data. A very
strange thing appears when you assign completely different data to
inappropriate variable type. ODE silently "merges" input data with
destination variable type that the result has the first tag the same as
destination type, but payload is from input data...
- Last my JIRA entry ODE-263. onAlarm is not working. It generates alarm
only after completed activity, not after specified amount of time. In
other words it doesn't work. We want use this functionality as a timeout
guard, but because of that we need to implement this functionality
outside ODE.
- Some useful extensions like external variables or adding own
activities are not in stable ODE version. We cannot rely on trunk.
Faster releases would be appropriate.
Apart from that we are almost on production with our new product. But
when we started we thought everything would be much easier.
--
Mateusz
Re: Logging from BPEL script
Posted by Alex Boisvert <bo...@intalio.com>.
2008/5/6 Nowakowski, Mateusz <Ma...@sabre-holdings.com>:
> Thank you
>
> I've also think about this workaround... but we didn't decide to do that
> way, because it is too complicated and resource consuming... logging should
> be as fast as possible...
> I think that log activity should be present in the standard, but the
> behavior should depend on the implementation.
Have you considered using the events that Ode generates?
> BPEL/ODE is annoying me slowly... It is very difficult to do very easy
> things and we need to discover very ugly workarounds to make things work
I would be interested in hearing more about these. What are your top
itches?
alex
Re: Logging from BPEL script
Posted by Jens Goldhammer <je...@googlemail.com>.
Hello,
just my two cents.
2008/5/6 Nowakowski, Mateusz <Ma...@sabre-holdings.com>:
> Thank you
>
> I've also think about this workaround... but we didn't decide to do that
> way, because it is too complicated and resource consuming... logging should
> be as fast as possible...
> I think that log activity should be present in the standard, but the
> behavior should depend on the implementation.
Maybe you can log with an esb. If you want a fast implementation, you can
take Synapse (synapse.apache.org) or WSO2 ESB(Synapse+Admin Console,
www.wso2.org). It is very easy to define mediations which log your
soap-messages and they have a streaming api based on AXIOM. They work on the
integration of ODE (
http://wso2.org/wiki/display/esbjava/WSO2+Enterprise+Service+Bus+Roadmap)
and want to enhance the monitoring part of their esb. Maybe they will
implement a mechanism to log steps from ODE? I don´t know exactly, maybe you
can ask them on the mailing list...
>
>
> BPEL/ODE is annoying me slowly... It is very difficult to do very easy
> things and we need to discover very ugly workarounds to make things work
But I think this is not the intention of BPEL to do easy things. BPEL is
only valuable if you have parallel service calls or by using the
bpel4people-spec which is not present in ODE where you can use generated
user-interfaces for inputs to your process. BPEL still lacks on great tool
support, faultless os server implementations and the mentioned reuse
problem. The declarative programming has not only its good sides :-) Open
Source has not the variety (ODE is good, but still have some faults)-
commercial software is in general very heavy (think of IBM Process
Server)... Maybe you can have a look at ActiveBPEL...
I think, it would become easier if bpel would define interfaces how to
interact better with the bpel server. The human-task-api of ibm shows how it
can be done in a small part. If you have a good java-framework like jbpm or
something else, you can do a lot of the bpel-stuff in java and just better
and faster!
Sorry, but that´s my opinion for today. Maybe it will change in future?
>
> --
> Regards
> Mateusz Nowakowski
>
> -----Original Message-----
> From: Łukasz Budnik [mailto:lukasz.budnik@gmail.com]
> Sent: Tuesday, May 06, 2008 12:39 PM
> To: user@ode.apache.org
> Subject: Re: Logging from BPEL script
>
> Hi Mateusz,
>
> I'm currently working on a system that manages BPEL processes.
>
> One of its features is enhancing original BPEL definitions by defining
> new partner link (logging web service) so that I can log almost
> everything ;)
>
> Enhancement is simply done by transforming BPEL with XSLT.
>
> My system (beta) will be available in 2 months time, I can let you
> know when it will be ready.
>
> best regards
> Łukasz
>
> 2008/4/28 Nowakowski, Mateusz <Ma...@sabre-holdings.com>:
> > Hi
> >
> >
> >
> > Is there any possibility to log some information from BPEL script?
> >
> >
> >
> > I think about some additional activity. Probably there isn't such
> > activity but as I know there is possibility to implement and add own
> > activity to BPEL.
> >
> >
> >
> > How can I add new activity to ODE? Is there any description how to do
> > that?
> >
> >
> >
> >
> >
> > --
> >
> > Regards
> >
> > Mateusz Nowakowski
> >
> >
> >
> >
>
RE: Logging from BPEL script
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
Thank you
I've also think about this workaround... but we didn't decide to do that way, because it is too complicated and resource consuming... logging should be as fast as possible...
I think that log activity should be present in the standard, but the behavior should depend on the implementation.
BPEL/ODE is annoying me slowly... It is very difficult to do very easy things and we need to discover very ugly workarounds to make things work
--
Regards
Mateusz Nowakowski
-----Original Message-----
From: Łukasz Budnik [mailto:lukasz.budnik@gmail.com]
Sent: Tuesday, May 06, 2008 12:39 PM
To: user@ode.apache.org
Subject: Re: Logging from BPEL script
Hi Mateusz,
I'm currently working on a system that manages BPEL processes.
One of its features is enhancing original BPEL definitions by defining
new partner link (logging web service) so that I can log almost
everything ;)
Enhancement is simply done by transforming BPEL with XSLT.
My system (beta) will be available in 2 months time, I can let you
know when it will be ready.
best regards
Łukasz
2008/4/28 Nowakowski, Mateusz <Ma...@sabre-holdings.com>:
> Hi
>
>
>
> Is there any possibility to log some information from BPEL script?
>
>
>
> I think about some additional activity. Probably there isn't such
> activity but as I know there is possibility to implement and add own
> activity to BPEL.
>
>
>
> How can I add new activity to ODE? Is there any description how to do
> that?
>
>
>
>
>
> --
>
> Regards
>
> Mateusz Nowakowski
>
>
>
>
Re: Logging from BPEL script
Posted by Łukasz Budnik <lu...@gmail.com>.
Hi Mateusz,
I'm currently working on a system that manages BPEL processes.
One of its features is enhancing original BPEL definitions by defining
new partner link (logging web service) so that I can log almost
everything ;)
Enhancement is simply done by transforming BPEL with XSLT.
My system (beta) will be available in 2 months time, I can let you
know when it will be ready.
best regards
Łukasz
2008/4/28 Nowakowski, Mateusz <Ma...@sabre-holdings.com>:
> Hi
>
>
>
> Is there any possibility to log some information from BPEL script?
>
>
>
> I think about some additional activity. Probably there isn't such
> activity but as I know there is possibility to implement and add own
> activity to BPEL.
>
>
>
> How can I add new activity to ODE? Is there any description how to do
> that?
>
>
>
>
>
> --
>
> Regards
>
> Mateusz Nowakowski
>
>
>
>
Re: Logging from BPEL script
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi Mateusz,
when you're on the trunk all you need is basically ready but yet
undocumented.
Starting points are
org.apache.ode.bpel.runtime.extension.AbstractExtensionBundle and the
*Operation classes in [1].
You could also have a look at [2] for an example.
Your custom ExtensionBundle can then be registered in Ode's config file
(ode-{1}.properties) via the ode-{1}.extension.bundles key.
{1} expands to (axis2|jbi)
HTH,
Tammo
[1]http://svn.apache.org/viewvc/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/extension/
[2]http://svn.apache.org/viewvc/ode/trunk/extensions/e4x/src/main/java/org/apache/ode/extension/e4x/
Nowakowski, Mateusz wrote:
> Hi
>
>
>
> Is there any possibility to log some information from BPEL script?
>
>
>
> I think about some additional activity. Probably there isn't such
> activity but as I know there is possibility to implement and add own
> activity to BPEL.
>
>
>
> How can I add new activity to ODE? Is there any description how to do
> that?
>
>
>
>
>