AM Tree Single Outcome Message

Dear community,
I’d like to show a message with only a positive answer to users in an AM 7.5 self hosted environment. There is a Message node (Message node :: PingAM 7.5.0), but its option ‘Only Positive Answer’ is only available in a Platform Deployment.

I can use a scripted decision node with the appropriate callbacks to mimick the desired behavior, but this results in one Scipted Decision Script for each Message I’d like to show.

Do you know of a mechanism to ‘inject’ message and button strings to a decision node script from within a tree? If this would be possible I could make one decision node script that gets its values via the aforemention mechanism.

Thanks in advance and best regards
Dennis

Hi @destracke,

I would use a Library script for that, available with Next Gen scripting.

  • In the library script, implement the callback processing.
  • Use a scripted decision node (Next gen) that
    • imports the library script
    • call the lib function with required scope, message, button text

Regards
Patrick

Hey Patrick,

Library script would help in abstracting the callback processing part. However, we still need to create a new scripted decision node every time we want to add a message. I’ve encountered this issue in my projects too, and having multiple scripts just for adding messages isn’t ideal.

It would be really helpful to have a node called Set node state property, like the Set session property node. This would allow us to dynamically pull data from the node state and display it. This feature would not only help with @destracke’s use case but would be useful in many other situations as well.

Is there any way to achieve this right now?

@anishetty / @patrick_diligent Thanks for your replies!

I also support what anishetty writes. To prevent script amount inflation, a ‘Set node state property’ would be awesome. Alternatively, if Ping would make the Message node behave the same way in a non Platform deployment (where we can chose to show only a single button), that would be another solution.

One question regarding the library solution: documentation explicitly states that bindings are not available in a library. Would that mean that one has to pass binding as function parameters into the library script?

Best regards
Dennis

Yes, you have to pass down the bindings. And agreed, but this is your best option until Ping bridges the gap. Having a visible configuration panel showing configuration for a scripted decision node would be ideal - no need then to dive deep into the script to reveal those parameters used by the script.

Before scripting next generation was available, our best option has been to develop custom java nodes to fill that gap, this increased configuration visibility and re-use. With scripting V2 now available, we are slowly converting the custom nodes to scripted decision nodes, but we will loose visibility on configuration. Unfortunately, custom java nodes is a blocker to moving to the cloud (unless one could manage to have Ping adopt your custom node for marketplace).

Anyway, here is a solution we came up with developing a script V2 library:

  • A calling script
  • An intermediate script which handles passing bindings, configure a specific logger, mix in config from caller, and any other boiling plate code - e.g placing there any non-functional stuff without having to change neither caller or callee.
  • The actual library that implement the function

So the calling script goes like this:

var handler = require("Lib:Handler:TextOuputCallback");

var NodeContext = {
    logger : logger,
    action: action,
    nodeState: nodeState
};

var objectAttributes = {
    "Active" : true
};

outcome = handler.process(NodeContext, { message: "Hello World" } );

Regards
Patrick

1 Like