I am trying to call a processing rule from a gatewayscript by using the Multistep module. However, I am unable to create a message object from my context to pass it as a parameter to the call rule statement. I am following the examples from the documentation : 

multistep module - IBM Documentation

When in debugging mode, I can see that the context.createMessage from the example below is undefined : 

var ms = require('multistep');

var fooObj = context.createMessage('foo');

I have tried to create my context by using the session.createContext(), to no avail.

Thank you!

------------------------------
Mathieu Laroche
------------------------------

For some reason I am unable to reply to this thread. Above is my original question, below is my reply Joseph Morgan's answer. 

Thank you for your reply. My question was indeed not precise enough.

I want to call a processing rule from a gatewayscrit. I want to use a custom input to pass to the programatically invoked processing rule (custom input, custom headers).

To achieve this, I am following the IBM's documentation : 

session object

APIs to manage messages

multistep module

I am trying to do exactly this (excerpt from the multistep module documentation) :

var ms = require('multistep');

var fooObj = context.createMessage('foo');
var barObj = context.createMessage('bar');

fooObj.body.write('HelloWorld');
fooObj.header.set('Header1', 'myHeader');
fooObj.setVariable('Var1', 'myVar');

ms.callRule('ruleAPIGW', 'foo', 'bar', function(error) {
  barObj.body.readAsBuffer(function(error, buf) {
    var OutputPayload = buf.toString();
    var OutputHeaders = barObj.header.get();
    var OutputVar1 = barObj.getVariable('Var2');
  });
});

However, I never seem to be able to create a "context" variable that has the "createMessage" method available (it is always undefined). So my main problem is creating correctly the context object (I have tried the session.createContext() method without success)

Thank you

OK.  So, I'm not sure exactly what you're trying because of the overly simple example.

(There is some kind of bug in the community pages preventing me from posting my example GWS here - message me privately and we may can bypass the bug there).

The GWS in the first rule calls the second rule.  

EDIT:  I just realized I can post a screenshot of the GWS:  Here it is:

------------------------------
Joseph Morgan
------------------------------

Hi.  Though I answered in our private messaging while this thread was stuck in moderation, here is the changed code to handle what you are talking about.  For the record, and for no understandable reason, there seems to be no way to post my solution in the code window (Some bug on the site).  So, maybe this will work:

Hi Mathieu,
First, in the DataPower 10.6.0.x documentation you reference, context is only for an API Gateway Service GatewayScript, thus if you're using the variable context in a traditional service like a MultiProtocol Gateway, context will be undefined.  Instead, your contexts should be standard MPGW contexts created with session.createContext('somename') if creating them in code, or contexts created previously as the output of some DataPower action.  Just a best practice I'm also used to, I believe createContext may cause an exception if you attempt to create it while it already exists, so unless you're absolutely sure it will or will not exist, I habitually do

var myCtx = session.name('myContext') || session.createContext('myContext');

if myContext exists, then you'll have a reference to the existing context, but if it doesn't, session.name will return an undefined and the or clause will do the session.createContext, providing you with a reference to the newly created context.

Since the links you provide are to the DataPower 10.6.0.x documentation, I would also suggest you take a hard look at two new functions in the multistep module that take all of the heavy lifting of understanding the requirements of ms.callRule.  If calling from a MPGW, you would simply need to call the ms.callRuleWrapper function and provide it a JSON object with the options properties containing the rule to call, an input child object that would indicate the name of the MPGW context you wish to read and pass a payload and headers from, and and output child object that would indicate the name of the MPGW context you wish to take the response of the called rule and write it to, some callback function  references if you wish to do some special handling before and after the rule is called and also add any custom error processing if needed.  The point of the function is that it takes all of the heavy lifting out of your code and lets the multistep function handle it all for you.

The 2nd function, callRuleWrapperInit, is mostly beneficial as a setup like function to the callRuleWrapper function when calling from an API Gateway user defined policy, although it will also return an object which some debug helpful variables that you can use for logging assistance.

Best Regards,
Steve Linn