Custom Properties in bpm-platform.xml

[matth...@gmail.com]

Hi all,
I have some Service Tasks that should use a configuration.

In my case, I have a some service tasks that call a RESTful Web Services. For this I use the expression on a service task like this: (#{restCaller.get(execution, 'policies/{policyId}/premium')} )

In the CDI @Named class, I call the service. For this reasons, I need the server name and username/password from a batch user.

I think the right place for this could be bpm-platform.xml. In this file, I have already defined my IdentityService with some configuration stuff.

Now my problem is, I don't know how I can get information from bpm-platform.xml.

In my service task I have only the class DelegateExecution

Do you have any ideas for me?

Thanks, Matthias

[Bernd Rücker (camunda)]

Hi Matthias.

The information you describe for me would go into a service registry. So I
would actually design a mini registry in this case - and not add these
configurations to the process engine. A mini registry could be a simple
properties file in your classpath or application server properties or a
database table or the like. This would be the preferred way in my eyes.
Did that a couple of times at customers already - works pretty well :-)

So in case of CDI that could be a

@Inject
ConfigurationService

Or
@Inject
ServiceRegistry

With a simple backend reading a properties file in the background.

WDYT?

Cheers
Bernd

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von
matth...@gmail.com
Gesendet: Freitag, 13. Dezember 2013 00:50
An: camunda-...@googlegroups.com
Betreff: [camunda-bpm-users] Custom Properties in bpm-platform.xml

--
You received this message because you are subscribed to the Google Groups
"camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/camunda-bpm-users/496c8d1d-9517-410c-90b
3-1f214b1f4e05%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[matth...@gmail.com]

Hi Bernd,
many thanks for you feedback!

Sure, a ServiceRegistry could be very easy implemented.

My thoughts for this was only to avoid too much configuration in different files. In my case, the bpm-platform.xml has to be modified in any case because of registration of my own IdentityService.

But if you recommend to introduce a little ServiceRegistry, I think I will do so. You're the BPM pro! ;-)

Ciao, Matthias

Am Freitag, 13. Dezember 2013 15:44:01 UTC+1 schrieb Bernd Rücker:
> Hi Matthias.
>
>
>
> The information you describe for me would go into a service registry. So I
>
> would actually design a mini registry in this case - and not add these
>
> configurations to the process engine. A mini registry could be a simple
>
> properties file in your classpath or application server properties or a
>
> database table or the like. This would be the preferred way in my eyes.
>
> Did that a couple of times at customers already - works pretty well :-)
>
>
>
> So in case of CDI that could be a
>
>
>
> @Inject
>
> ConfigurationService
>
>
>
> Or
>
> @Inject
>
> ServiceRegistry
>
>
>
> With a simple backend reading a properties file in the background.
>
>
>
> WDYT?
>
>
>
> Cheers
>
> Bernd
>
>
>

> -----Urspr�ngliche Nachricht-----

>
> Von: camunda-...@googlegroups.com
>
> [mailto:camunda-...@googlegroups.com] Im Auftrag von
>

> matthias...@gmail.com

[Bernd Rücker (camunda)]

I simply think it is less hassle to create a new properties file (1 line
of code reading it) and you can control the whole code (instead of hooking
it into our XML file where you have potential overhead and maintenance
effort if we release new versions). But it is a free country ;-)

-----Urspr�ngliche Nachricht-----

Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von

matth...@gmail.com
Gesendet: Dienstag, 17. Dezember 2013 18:33
An: camunda-...@googlegroups.com
Betreff: Re: [camunda-bpm-users] Custom Properties in bpm-platform.xml

Hi Bernd,
many thanks for you feedback!

Sure, a ServiceRegistry could be very easy implemented.

My thoughts for this was only to avoid too much configuration in different
files. In my case, the bpm-platform.xml has to be modified in any case
because of registration of my own IdentityService.

But if you recommend to introduce a little ServiceRegistry, I think I will
do so. You're the BPM pro! ;-)

Ciao, Matthias

Am Freitag, 13. Dezember 2013 15:44:01 UTC+1 schrieb Bernd R�cker:
> Hi Matthias.
>
>
>
> The information you describe for me would go into a service registry. So
I
>
> would actually design a mini registry in this case - and not add these
>
> configurations to the process engine. A mini registry could be a simple
>
> properties file in your classpath or application server properties or a
>
> database table or the like. This would be the preferred way in my eyes.
>
> Did that a couple of times at customers already - works pretty well :-)
>
>
>
> So in case of CDI that could be a
>
>
>
> @Inject
>
> ConfigurationService
>
>
>
> Or
>
> @Inject
>
> ServiceRegistry
>
>
>
> With a simple backend reading a properties file in the background.
>
>
>
> WDYT?
>
>
>
> Cheers
>
> Bernd
>
>
>

> -----Urspr�ngliche Nachricht-----

https://groups.google.com/d/msgid/camunda-bpm-users/59130825-9a92-4f63-84b
0-e5eb508989e2%40googlegroups.com.