Jiri, this is as expected.  When using the local API, an instance that implements WorkflowProcessInstance is returned.  However, when using the remote API, we only return an instance that contains the basic information of the process instance (basically the information as seen in JaxbProcessInstanceResponse, similar as what is found in the ProcessInstance interface).  It is not returning the full information about the process instance (as this is not recommended for remote operations).

Therefore, I believe it is as designed that the ProcessInstance returned cannot be cast to WorkflowProcessInstance.

@Jiri, should we close this of as not a bug?

Kris,

Thank you for your answer.

I need to insert an instance of WorkflowProcessInstance into a working memory in order to fire a rule engine. 

"It is not returning the full information about the process instance (as this is not recommended for remote operations)."

Unfortunately this statement creates new questions. It seems that JaxbProcessInstanceResponse cannot be inserted into the working memory in order to fire the rule engine, because it lacks all the necessary information.

1. Are rule tasks supported for remote API?
2. How are users supposed to run processes with rule tasks using the remote API?

I think that processes with rule tasks and rule task operations should be supported. I think it is a major use case for customers. By omitting this feature we may force customers to write own wrapper applications, for example like [1]. I mean the situation can repeat like with BRMS 5.3.x.

[1] https://github.com/jboss-gpe/processFlowProvision

Yes, rule tasks are supported through the remote api.  

But in general rule tasks don't require the insertion of the process instance into the working memory (while technically possible, I believe the recommendation should be to try and avoid this).  I assume this might be to be able to change a process instance variable from a rule? Alternatively, custom objects could be inserted in the working memory instead, where the rules would modify the objects, and an on-exit script would copy the results into process variables afterwards.  Also, in most cases the objects are inserted as part of the process itself (for example in a script task) rather than through separate insert / update commands.

So I'm not sure in which cases inserting a process instance through the remote api would be necessary (I would only recommend that if all other possibilities don't work).

It might be worth checking if a composite command could be used instead though (instead of returning the process instance to the client, passing it immediately to a second command to insert it).

Do you have a use case in mind where the use of a rule task would require the user to insert the process instance remotely (where inserting the process instance can't be avoided and can't be done as part of the process)?

Kris,

What is the difference between what he is doing (or trying to do) and the Customer Evaluation demo unit test that approaches this the exact same way?

https://github.com/eschabell/bpms-customer-evaluation-demo/blob/master/projects/customer-evaluation-demo/src/test/java/customer/evaluation/CustomerEvaluationTest.java

See the last test at the bottom, it is the same code and seems to work for ER5 as the output here shows from a 'mvn test' on the project:

=============================================
= Starting Process Empty Request Test Case. =
=============================================
Entering Initialize Node
There as no evaluation objects defined, adding default ones for demo purposes.
Leaving Initialize Node
Gateway: Qualify Age
Gateway: Qualify Age
Entering Underaged Node
Detected and reporting invalid request.
Set validRequest to: false
Leaving Underaged Node
Process ended in End Minor Node.
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.143 sec

This project uses a reference to the kjar to facilitate the unit test.

(In reply to Kris Verlaenen from comment #3)
> Yes, rule tasks are supported through the remote api.  
> 
> But in general rule tasks don't require the insertion of the process
> instance into the working memory (while technically possible, I believe the
> recommendation should be to try and avoid this).  I assume this might be to
> be able to change a process instance variable from a rule? Alternatively,
> custom objects could be inserted in the working memory instead, where the
> rules would modify the objects, and an on-exit script would copy the results
> into process variables afterwards.  Also, in most cases the objects are
> inserted as part of the process itself (for example in a script task) rather
> than through separate insert / update commands.
> 
> So I'm not sure in which cases inserting a process instance through the
> remote api would be necessary (I would only recommend that if all other
> possibilities don't work).
> 
> It might be worth checking if a composite command could be used instead
> though (instead of returning the process instance to the client, passing it
> immediately to a second command to insert it).
> 
> Do you have a use case in mind where the use of a rule task would require
> the user to insert the process instance remotely (where inserting the
> process instance can't be avoided and can't be done as part of the process)?

(In reply to Eric D. Schabell from comment #4)
> Kris,
> 
> What is the difference between what he is doing (or trying to do) and the
> Customer Evaluation demo unit test that approaches this the exact same way?

@Eric, your test is not using the remote REST api, it's using a local ksession, so in that case you do get a full ProcessInstance as result (containing all data), not a remote wrapper.

Jiri, I would suggest lowering to priority of this issue to medium (based on the fact that I'm not sure inserting a process instance through remote API is actually a common requirement), would you agree?  

Or do you believe we should try the composite command approach first?

I think we should try the composite command approach first. Can you send me a link or a command snippet how to use that?

If this approach will work, we can reduce the priority of the issue.

(For others reading this bug:)

One of the issues surrounding this issue is that the remote API is meant as a remote way to access the internal execution-server. As such, it's only meant to support jBPM operations -- the scope of the operations does not cover drools. 

However, some drools and jbpm functionality overlaps, such as support of rule tasks. That's why there's a fireAllRules operation available via the remote Java API. While that operation is available, it certainly does not mean that full support of drools operations should be expected, such as being able to insert fact regardless of the type of fact: 1. this is an API to support jBPM and 2. this is a remote API which means it never will (and never should!) cover the same operations as the local API.

For the reasons described above, I would like to, at the very least, lower the priority of this bug. 

Furthermore, I've provided an example in which fireAllRules() works: 
https://github.com/droolsjbpm/kie-tests/blob/6.0.x/remote-kie-tests/kie-wb-tests/kie-wb-tests-base/src/main/java/org/kie/tests/wb/base/methods/RestIntegrationTestMethods.java#L609

This example uses process variables instead of facts. Furthermore, since FactHandle instances are complex non-(trivially)-serializable object-trees, we use the auditLogService to verify the value of the variable output by the rule task instead of using the FactHandle interface.

Apologies, the actual example can be found here: 

https://github.com/droolsjbpm/kie-tests/blob/6.0.x/remote-kie-tests/kie-wb-tests/kie-wb-tests-base/src/main/java/org/kie/tests/wb/base/methods/AbstractIntegrationTestMethods.java#L98

(It uses the ruleTask.bpmn2 and ruleTask.drl files found here: 
https://github.com/droolsjbpm/kie-tests/tree/6.0.x/remote-kie-tests/kie-wb-tests/kie-wb-tests-base/src/main/resources/repo/test )

This example can be run using both the local and remote API's.

Composite commands are currently not yet supported in the remote APIs, so while I believe this would work once they are supported, it is currently not yet possible.  Since we are currently not planning to add support for this currently for GA, I will remove the blocker flag for now.

Where are these composite commands documented? I have seen the RestAPI call, but interested in what can be done with them.

(In reply to Kris Verlaenen from comment #10)
> Composite commands are currently not yet supported in the remote APIs, so
> while I believe this would work once they are supported, it is currently not
> yet possible.  Since we are currently not planning to add support for this
> currently for GA, I will remove the blocker flag for now.

Eric, batch commands basically allow you to send multiple commands as one composite command to the server.  It even allows binding output from one command as input of another.  Some example can be found here:
http://docs.jboss.org/drools/release/6.0.0.Final/drools-docs/html_single/index.html#KIERunningSection (section 4.2.4.6)

https://bugzilla.redhat.com/show_bug.cgi?id=1044504 was closed as NOT A BUG. Lowering priority.

Remote kie client Java API has significant limitations when compared to the ordinary embedded use. It is possible to evaluate rule tasks remotely using this API, but with limitations.

These limitations should be clarified and documented in release notes or in documentation.

Further work, which should remove some of these remote API limitations was postponed to 6.0.1.

I believe support for composite commands would allow the use case as described.  So I'm updating the title and flags to reflect this, so we can consider this as a future feature request.

Hello Kris,

What is exactly meant by 'composite commands'? How it will solve the problem reported in the bug description? Will this feature be implemented in 6.1.0?

Thanks,
Jiri

Composite commands are batch commands -- and with a batch command, you could do multiple things (in one REST call) in order to accomplish your original goal. 

On the other hand, we could also just add an operation that does what you want. 

One of these 2 things is a solution for the original problem.

This is a feature request, not a bug.

I suppose, this is the feature request https://bugzilla.redhat.com/show_bug.cgi?id=1086799