How to invoke decision service as a stateless session in Kie (RedHat Decision Manager)

Question

I have just installed RedHat Decision Manager 7.3 and can deploy a decision service. So far, I have been using the /server/containers/instances/{containerId} endpoint to call my service, where the payload lists commands to insert objects into working memory.

However, this is a stateful session, and I am trying to work out how you call a decision service using stateless sessions. The documentation is not at all clear on how to do this via the REST API, but has plenty of examples if you were using the Java API (unless I have missed something).

Does anyone have any examples on how to do this via REST?

Any help is gratefully received.

UPDATE First I meant version 7.3 not 7.4, but the documentation looks the same.

So it looks like I was not a million miles away, it looks like from the documentation supplied that I need to specify a session Id in a lookup param, so my request will be something like this:

{
  "lookup": "mysession",
  "commands": [
    {
      "insert": {
        "object": {
          "com.indecision.baggage.Result": {}
        },
        "return-object": true,
        "out-identifier": "results"
      }
    },
    {
      "insert": {
        "object": {
          "com.indecision.baggage.Booking": {
            "fareClass": "First",
            "baggageItems": [
              {
                "com.indecision.baggage.BaggageItem": {
                  "width": 100,
                  "height": 100,
                  "depth": 100,
                  "weight": 20
                }
              }
            ]
          }
        },
        "return-object": true,
        "out-identifier": "booking"
      }
    },
    {
      "insert": {
        "object": {
          "com.indecision.baggage.FlightInformation": {
            "currentWeight": 100000,
            "flightNumber": "IA001",
            "maxOperatingWeight": 200000
          }
        },
        "return-object": true,
        "out-identifier": "flightInfo"
      }
    },
    {
      "fire-all-rules": {
        "out-identifier": "firedActivations"
      }
    }
  ]
}

However when I send in the request, I get the following error message:

{
  "type": "FAILURE",
  "msg": "Error calling container Indecision-Airlines-Baggage-Fee-Calculator: Session 'mysession' not found on container 'Indecision-Airlines-Baggage-Fee-Calculator_1.0.0-SNAPSHOT'.",
  "result": null
}

Now in RH Business Central under the server configurations you can specify a session Id for the decision service, but the Save button is always greyed out regardless of what I try. So my first question is any ideas as to why or how enable the setting of this config?

My second question is if session Id's have to be defined up front then really these services cannot be truly stateless across multiple requests? As I see it, they would need to up front specify what session Id they want to execute under, rather than new requests having a new session created for them by the KIE engine. Or have I got that wrong?

Again thanks in advance for any answers.

Answer 1

You can reference this document for RHDM v7.4 API to interact with a knowledge session via either the Java API or REST API: doc link

I believe is a pertinent document so it will show you side-by-side the Java API and its REST API equivalent, so you can use it for your use-case.

The example reported there is relevant to stateless session as well, as long as you use the Batch command to wrap all of your commands; in other words, to me the examples reported in that document are expected to work with stateless session, no problem. If you experience otherwise don't hesitate to report it as a bug

Following the update on the original question

Q1: no, the attached screenshot in the question is about "process configuration". If you want to name a session purposefully, with your Project open in Business Central in the horizontal tab "Settings" in the vertical tab "Kie bases" you can edit the equivalent of the kmodule.xml and name your knowledge bases and session as desired. This identifier will then be the one to reference with the batch command.

Quick example screenshot for your reference:

Please notice on Business Central kmodule definition of session are by default stateless, which is expected.

Q2 not really, as described in the Drools/DM manual, a stateless session reference is not persisted/stateful, so what will happen is that your request will be handled in a stateless manner (because it's indeed a stateless session).

In other words, for any request sent to that stateless session named "mysession", a stateless session instance will handle your request, transparently.

You do not have to configure one session name per request.

Answer 2

I don't have enough reputation points yet to add a comment on tarilabs' answer, so I'm letting you know here as another answer that we've updated the KIE APIs document that tarilabs mentioned (for Red Hat Decision Manager and Process Automation Manager, and for Drools in community) with a note clarifying how to view or change a KIE session ID for use in the lookup command attribute. Hopefully this will help other users who have your same question. And thank you for raising that ticket about the issue you faced when you tried to modify the KIE session setting.

Also, I've shared with you the 7.4 version of that doc (although the same is updated in 7.3 as well) because I wanted to make you aware of a new Direct Documentation Feedback feature in our Red Hat Decision Manager and Process Automation Manager docs starting 7.4. You can highlight any part of the doc, click Add Feedback, and provide documentation feedback directly to our docs team to be assessed, prioritized, and addressed. For more info about this feature, see this announcement in the Red Hat Customer Portal.

If you have any other specific questions or suggestions for our Decision Manager or Process Automation Manager documentation, feel free to use that feedback feature in the Customer Portal. For community docs, feel free to use the community channels that tarilabs mentioned.

Thanks again for your feedback, Justin!