December 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins

by apestel

Here are two examples / use cases: --------------------------------------------------------------- First, we have an organization that wants to accept loan applications via web services from various sources. In this case, the logical loan application process is a long running process containing human tasks. So, they want to expose one Web Service on the ESB that accepts the loan application and begins processing it. An email will be sent when the application is approved or denied, but they also want to provide a mechanism for the requester to check status while the process is running. So, they want to expose a second web service on the ESB that allows the requester to get back status on the loan application in process. This status may be stored in a textual jBPM variable or maybe the ESB service returns the root token's current process node name or something. The point is, without the process instance ID that was created with the application submission, how will the status check web service be able to know which process ID to check for intermediate status? --------------------------------------------------------------- Second use case - something NAVTEQ was wanting to do and something another SA's customer was wanting to do (among others): Customer wants to do BPEL like service orchestration but leverage the JBoss ESB concept of a service rather than be limited to and deal with the complexity of SOAP services. For this case, let's use the same loan application example, but let's say that now the loan application process is completely automated. There is still the initial SubmitLoanApplication WS, but it actually synchronously returns an approved or denied message. There are several steps to the loan application. First, we need to validate the application (ValidateApplicationService), then, we need to do a quick credit check (CreditCheckService), then we need to check for existing loans (RetrieveExistingCustomerLoans), then, we need to calculate a loan rate based on customer info, credit score, etc. (CalculateLoanRate), finally, we need to kick off a separate process that starts the loan process or puts the loan in a queue or something. Of course, there are conditional paths in here too. For example, based on the type of loan, we may call different CacluateLoanRate service or something, or if the RetrieveExistingCustomerLoans actually returns some existing loans, we may need to do some checking on them, etc. So, customer has these individual services exposed on the bus. They've got the orchestration of the service defined in jBPM so they can create it easily, see it easily, change it easily without pausing acceptance of applications, etc. They want the initial SubmitLoanApplication WS to accept the request, synchronously kick of the jBPM orchestration, wait for the process to finish, and return the contents of a loanDecision jBPM variable or something more complicated. Currently, the only way to do something like this (that I'm aware of) is with Sync Continuation which means the customer really has to understand the internals of our ESB, has to create a separate replyTo service in the ESB and update the jBPM process to call back to it so that the replyTo service can response to the replyTo endpoint of the original SubmitLoanApplication WS that is basically hanging out there waiting for a reply-to message. I'm sure some of my terminology is wrong there, but the point is that the customer doesn't want to hear about that complexity. They want to just create a SubmitLoanApplication WS, have that service kickoff the jBPM service orchestration, and return a result when the jBPM process finishes. --------------------------------------------------------------- Please let me know if these do not make sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197725#4197725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197725

16 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - JBPM_VARIABLEINSTANCE null value

by btl_ayd

Hi I made a simple application with jbpm.When I starting new task I saw null value on the JBPM_VARIABLEINSTANCE.Why null value is occuring on this table can anybody explain? Ä°s it a bug? I use jbpm 3.2.3 versiyon here is my procesdeffinition.xml | | <process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="calisma"> | | | <start-state name="start-state1"> | <transition to="gorev" name="git"></transition> | </start-state> | | | <task-node name="gorev"> | <task name="gorev"> | <assignment actor-id="manager"></assignment> | <controller> | <variable access="read,write" name="ad"></variable> | </controller> | </task> | <transition to="end-state1" name="but"></transition> | </task-node> | | | <end-state name="end-state1"></end-state> | | | </process-definition> | here is table value when task has been started. ID_ CLASS_ VERSION_ NAME_ CONVERTER_ ------------------ 1 N 1 null 2 s 0 ad ................................................................ I want to know the why value of first row is null how can I correct this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197724#4197724 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197724

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: java.util.logging Bridge Component

by david.lloyd＠jboss.com

Two random thoughts: One logging feature that we seem to be missing in JBossAS that could be desirable is the notion of segregated logging contexts. Looks like log4j has some support for this via RepositorySelector but I don't think we're really using it...? In any case, JDK logging doesn't have this notion; though it shouldn't be too tough to modify the LogManager to support this. Also, there's currently a deficiency in the LogBridge design. It relies on a root JDK logger with a permissive log level like ALL, which would defeat the usual "isLoggable(level)" checks for things using JDK logging (JSF in particular would probably suffer from this). The solution would be to make sure that level changes are propagated between log4j and JDK logging, which might take some fiddling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197716#4197716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197716

16 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1607 Update EJB3.0 Tutorials

by jaikiran

r82451 now contains the updated dependencies for the Maven plugin. It also containing additional tutorials like "stateful" and "jndibinding" in addition to the earlier "stateless" tutorial. I had plans to add a few more tutorials during this commit, but i see a probable issue in Maven where the plugin execution order isn't as per their documentation. I'll investigate more into this on Monday. I have done a local Hudson run against this revision with JBossAS-5.0 GA. It went of successfully. By the way, there's now a wiki with the details to run the tutorials https://www.jboss.org/community/docs/DOC-13215 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197714#4197714 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197714

16 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: https://jira.jboss.org/jira/browse/JBMESSAGING-1460

by clebert.suconic＠jboss.com

a typo... It should be on 1.4.2 and 1.4.3 i added the target versions yesterday, as they were missing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197704#4197704 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197704

16 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Calculating paging after routing

by clebert.suconic＠jboss.com

Tim: Why did you remove the PageStore creation on the PostOffice. I already told you I need that to resume Paging on restart. I can't just have the Destinations created Lazily. I need to know what valid Addresses I have on the system on restart. You also disabled the method on AddressManager. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197683#4197683 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197683

16 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins

by Kevin.Conner＠jboss.com

"apestel" wrote : SignalCommand, CancelProcessInstanceCommand, and setProcessInstanceVariables Signal and setProcess should have been removed in the rewrite but weren't. Signal is severely broken and you should not be modifying *any* process variables other than through the interactions with jBPM. It is up to jBPM to drive that process. "apestel" wrote : If someone uses the ESB to kick off a process instance and they also want to use the ESB to be able to cancel that same process. Agreed, and that is the only useful use case so far. "apestel" wrote : In addition to this is the even more common case I run into where the customer (NAVTEQ most recently) want to use BPM for service orchestration. So, client invokes a service on the ESB and that ESB service needs to synchronously kick off the orchestration of other services, aggregate a result, and return it to the original client. Having things done 'synchronously' in an ESB does not imply synchronous invocations. "apestel" wrote : I've been telling folks to just not even use BpmProcessor and to implement their own custom action instead that invokes/controls the BPM process. I see many more real life use cases for a synchronous BpmProcessor than an asynchronous BpmProcessor. Synchronous BpmProcessors mean nothing in this environment. If you create a business process then you are ceding control to that process but that does not mean that you cannot receive notifications/replies from it. "apestel" wrote : If this action were updated to support synchronous use, it would be nice to generically support "bpmToEsbVars" in addition to "esbToBpmVars" to be consistent with the way things are done when jBPM invokes an ESB service. Synchronous invocation of the jBPM APIs is not necessary for integration with jBPM and is inadvisable for a number of reasons, including its effect on transactions and thread usage. If you can send me an example where you think this is necessary then I will look at it and see how it can be reworked. If we are missing something then we can add it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197680#4197680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197680

16 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover on LargeMessages

by clebert.suconic＠jboss.com

anonymous wrote : II - I can't just let the backup-node call largeMessageSender.send, or the backup could be running faster than the server. (Running out of Credits first for instance). This is the main issue. When I send a message from Server2Client, I will verify that is a LargeMessage, and start a loop on sending the several chunks. If I just call largeMessageSender.send on the backup, I could the backup flooding flowControl before the liveNode. A lot of uncertain events could happen followed after that. Example... - Master will send an 1G Message. - It will replicate the send to the backup - Backup will start sending the 1G Message. It will immediately flood flow control. (There is no actual sending on backup). - Master will receive credits and replicate them to backup - Master will send another 1G Message (Eventually, the backup will still be sending the previous message, I have seen situations where the flowControl still full on backup, and that will reject replications from the masterNode). We need a sync between Master and Backup to solve that. Or I implement that sync chunk by chunk, and failover would resume from that chunk, Or I sync just a start and end, and failover would reset the pointers and file and resume from the beggining of the file again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197679#4197679 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197679

16 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Calculating paging after routing

by clebert.suconic＠jboss.com

"timfox" wrote : However I notice that that didn't break any tests.. I don't know what you did in your loca copy, but the testsuite is broken all over the place because of paging. I'm taking a look. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197673#4197673 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197673

16 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins

by Kevin.Conner＠jboss.com

The callback EPR is necessary in order to correctly identify the state of the process and verify that we are doing the correct thing when the response arrives. If there is extraneous information in there then we should remove it. What is it that you feel needs 'cleaning up'? As for the process instance, I agree that it is useful if you want to cancel the process. Anything else and it should be done through jBPM. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197668#4197668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197668

16 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2008