ProcessFlow – M3 ideas

How to call a process flow from a Smart Office script

Here is a solution to trigger ProcessFlow Integrator (PFI) from a Personalized Script for Lawson Smart Office (LSO) using the native PF adapter. This technique is new as of LSO 9.1.3.

First, enable the PF configuration in the Smart Office Profile Editor:

Then, use Lawson.Shared.PF.Trigger to determine if Trigger Services are available:

if (PFTrigger.HasTriggerService) {
    // Trigger Services are available
} else {
    // Trigger Services are not available
}

PFTrigger is part of Lawson.Shared.dll:

Then, prepare the trigger:

var service = 'MyService';
var product = 'ERP';
var dataArea = 'PFTST';
var category = '';
var title = 'Test from a script';
var trigger = new PFTrigger(service, product, dataArea, category, title);
trigger.AddVariable('var1', 'Hello1', 'String');
trigger.AddVariable('var2', 'Hello2', 'String');
trigger.AddVariable('var3', 'Hello3', 'String');

Then, execute the trigger:

trigger.SubmitRequest(dataArea, OnTriggerCompleted);

Then, add an event handler:

function OnTriggerCompleted(args: PFTriggerEventArgs) {
    if (args != null && args.IsSuccessful) {
        args.Response.DetailMessage
        args.Response.ErrorCode
        args.Response.InformationCode
        args.Response.ReturnCode
        args.Response.ReturnData
        args.Response.Status
        args.Response.WorkunitNumber
    }
}

Here’s a screenshot of the result:

We can see the HTTP Request and Response with Fiddler:

For versions of Smart Office prior to 9.1.3, it’s possible to trigger PF flows using the old technique with URL. For that, you can use the PFI trigger generator.

The advantage of the new technique is the lower number of lines of code, increased readability, no need to hard-code the hostname, port, user, and password anymore, and no need to handle authentication nor logout.

That’s it!

How to loop M3 activity node in PFI

Here is a solution to iterate thru the result set of an M3 activity node in ProcessFlow Integrator (PFI).

Background

M3 API transactions of type Get return one record. For example, CRS610MI.GetBasicData returns information about the specified customer number.

M3 API transactions of type List typically return multiple records. For example, CRS610MI.LstByNumber typically returns thousands of records.

Problem

Unfortunately, the M3 activity node in PF Designer does not include an iterator:

As a consequence, we cannot iterate individually thru the records of the M3 output, nor can we use other activity nodes inside each iteration. For example, there are valid scenarios where I would like to do something at each iteration: send an email, assign a value to a variable, execute SQL, call a Web Service, or do something else, even though there could be thousands of iterations. It’s not possible by default.

Other nodes

There are other activity nodes that appropriately have an iterator. For example, the SQL Query activity node includes an iterator, so we can call other activity nodes at each iteration to do something with each record of the SQL result set:

Goal

The goal is to find a workaround to iterate thru the result set of an M3 activity node, as illustrated in this fake screenshot:

Workaround 1

One workaround is to iterate thru the M3_output.row array by using JavaScript code in an Assign activity node.

for (var i = 0; i < M3_output.row.length(); i++) {
    var row = M3_output.row[i];
    // do something
    row.fieldName1;
    row.fieldName2;
    row.fieldName3;
}

Where fieldName is the output field of the result set, for example: CONO, CUNO, CUNM, etc. Alternatively, we can use the other syntax for accessing JavaScript Object properties: row[“fieldName“];

But there are several drawbacks to this workaround. First, it requires programming, which counters the graphical paradigm of PF Designer. Second, we cannot call other activity nodes from that JavaScript code. Third, PF Designer throws the false positive error message that we can ignore: “ReferenceError: M3_output is not defined”.

Workaround 2

Another workaround is to use an Assign activity node to serialize the JavaScript object into a String with delimiters (for example a semi-colon), and then two DataIterator activity nodes to parse that String by row and by column. It’s a bit cumbersome but it works.

for (var i = 0; i < M3_output.row.length(); i++) {
    var row = M3_output.row[i];
    csv += row.fieldName1 + ';' + row.fieldName2 + ... + ';' + row.fieldNameN + '\n';
}

The drawback – in addition to being disconcerting for non JavaScript programmers – is that it will take a lot of CPU and memory to process a big result set because appending a String to a String is exponentially slower.

Workaround 3

The third workaround is to create a for loop using a Branch activity node. Indeed, a for loop can be transformed equivalently into a recursive function with an if statement.

Yes branch:

i < M3_output.row.length() - 1

No branch:

i >= M3_output.row.length() - 1

This is my recommended solution.

LPA

Note that this is not a problem anymore with the newest Lawson Process Automation (LPA) and Lawson Process Designer as the M3 transaction node now correctly includes an iterator:

That’s it!

Send SMS from PFI with Twilio

Here I propose a solution to send SMS text messages from M3.

The desired solution is an exchange of SMS text messages between M3 and the user.

Scenario

For example, let’s suppose we have a scenario where approvers need to review new Customers before setting the Customer’s status to 20-Definite in CRS610. Also, let’s suppose that the approvals are done by SMS text messages. In such a scenario, M3 would send an SMS text message to the user’s mobile phone saying “Please review and approve this new customer XYZ”. The user would respond with an SMS text message saying “APPROVE”. M3 would acknowledge receipt of the approval and would call the API CRS610MI.ChgBasicData to set the Customer’s Status to 20-Definite.

Here is a screenshot of such an exchange between M3 and the approver:

Alternate solutions

The current solutions for such approval scenarios is to use the Smart Office Inbasket, the Mailbox Inbasket, and the Mobile Inbasket of ProcessFlow Integrator (PFI). But those solutions do not support SMS text messaging.

Why it matters

SMS text messaging is a market of 6 trillion SMS text messages sent in 2010 [1], generating $114.6 billion in 2010 [2].

We want M3 to also benefit from the potential of using SMS text messages.

Background

In a previous post, I had posted a solution to Send SMS from Smart Office with Skype. That was a solution for the client-side.

This time, I post a solution using Twilio. And this time the solution is for the server-side.

How it works

I propose a solution that uses PFI and the REST API of Twilio cloud communications.

Twilio is a service that allows developers to programmatically make and receive phone calls, and to send and receive text messages. Twilio’s REST API is XML or JSON over HTTP.

Technically speaking, we want PFI to send an HTTP request to Twilio. The HTTP Request must be over HTTPS, using a POST method, using Basic Authentication, and the Body of the request will contain as parameters the source phone number, the target phone number, and the desired message. We’ll use the WebRun activity node in PFI for that. And when Twilio will receive that HTTP Request it will send the SMS text message on our behalf using its PSTN gateway.

Pre-requisites

Make sure your Twilio account works:

Open an account with Twilio
Add funds
Make sure to get a valid Twilio phone number
Test it with the Twilio Sandbox
Test it with the API Explorer
Write down the Account SID and the Authorization Token, they will be needed for authentication later:

Sample HTTP Request

A sample HTTP Request to send an SMS text message looks like:

POST https://api.twilio.com/2010-04-01/Accounts/ACec246b17f76e0f336a6........../SMS/Messages.xml HTTP/1.1
Authorization: Basic QUNlYzI0NmIxN2Y3NmUwZjMzNmE2NTYzMjI2ZmNmMTUyYzo1ZjA2MDA4NDI0ZGQ1OGFmNWZkMThiYW.........==
Content-Type: application/x-www-form-urlencoded
Host: api.twilio.com
Content-Length: 64

From=%2B14156250342&To=%2B18472874945&Body=Hi%2C+this+is+Thibaud!

Solution

Perform the following steps to implement the solution:

Open PF Designer
Create a new flow
Add a WebRun activity node:
Open the Properties of the WebRun activity node.
Set the WebRun to Use external host
Set the hostname to api.twilio.com
Set the userid to your Twilio’s AccountSid as shown on your Twilio’s account Dashboard.
Set the password to your Twilio’s AuthToken as shown on your Twilio’s account Dashboard.
Check the box SSL enabled
Set the Web program to:
```
/2010-04-01/Accounts/{AccountSid}/SMS/Messages.{format}
```
Where {AccountSid} is your AccountSid, and where {format} is either XML or JSON.
Set the Post string with a From, To, and Body parameters.
Set the source From phone number to your Twilio’s number, and URL-encode it. For example, the phone number +14156250342 becomes:
```
From=%2B14156250342
```
Set the destination To phone number to any number you want, and URL-encode it. For example, the phone number +18472874945 becomes:
```
To=%2B18472874945
```
Set the Body of the SMS text message to any text you want, and URL-encode it. For example, the message “Hi, this is PF Designer!” becomes:
```
Body=Hi%2C+this+is+PF+Designer!
```
Separate the From, To, and Body parameters with ampersands &
Set the Content-type to application/x-www-form-urlencoded.
But because PF Designer doesn’t have that specific content-type in the available list of options, you will have to add it manually in the XML file of the flow with a text editor like Notepad, and URL-encode it. The new value should be application%2Fx-www-form-urlencoded. The result should look like:
```
<activity activityType="WEBRN" ...>
  <prop className="java.lang.String" name="contentType" propType="SIMPLE">
    <anyData><![CDATA[application%2Fx-www-form-urlencoded]]></anyData>
  </prop>
  ...
</activity>
```
Save the flow
The Properties of the WebRun should look like this:
Run the flow:
Now your mobile phone should receive the SMS text message and beep. Here is a screenshot from the SMS text message received on my iPhone:
You can check the logs in Twilio:

Note: The WebRun activity node was meant for another purpose, to be used in conjunction with S3; we’re sort of deviating the WebRun activity node from its original purpose. So it will submit two more HTTP Requests to PFI – which are unnecessary to our solution – before submitting the HTTP Request to Twilio. It’s inefficient but that’s the only activity node of PFI that can natively submit HTTP Requests. UPDATE: I think I’m wrong here because I was testing from PFI Designer and that may have caused the two extra requests. When deployed the flow will probably not send them. To be verified.

Applications

Here are a few possible applications of sending and receiving SMS text messages from M3:

Support for users that do not have smartphones
Support for regions that are covered by GSM only and that lack coverage for 3G/4G/Wifi
Approve/Reject Customers (CRS610) by text messages
Approve/Reject Purchase Orders (PPS180) by text messages
Send driving directions to truck drivers
Send pick-up reminders
Place a Customer Order via text messages
Send notifications by text message when an order changes status.
Monitoring and alert. To help with the scheduled jobs, such as CAS950, OIS180, PPS600, POs, Invoicing, Stock Transactions, etc. If there is an issue, if the jobs fail or do not complete within the expected time, M3 could alert a maintenance staff via SMS text message to its mobile phone.

Future work

Here are future implementations:

In addition to sending text messages, we can receive text messages via Twilio, so as to have two-way SMS text messaging with the user.
As an alternative to PFI, we could use Twilio’s helper libraries in Java to send SMS text messages directly from M3 Business Engine with an MAK modification, i.e. without having to go thru PFI.
In addition to PFI and M3, we could send SMS text messages from Lawson Smart Office scripts with the Twilio’s helper libraries for .NET.

I will publish such solutions in future posts.

Conclusion

That was an easy solution to send SMS text messages from PFI. By extension, since M3 Business Engine can trigger PFI flows, we can consider this a solution too for M3 BE to send SMS text messages.

That’s it!

PFI trigger generator

The PFI trigger generator is a tool that generates source code to trigger a ProcessFlow Integrator flow in various programming languages and with various triggering options. I use it to ensure source code correctness, and to test the capabilities of Email clients. I hope it helps you too.

http://ibrix.info/pfi/

How to avoid impersonation with the Mailbox Inbasket for PFI

Here is a solution to avoid impersonation when from an email we take action in the Inbasket of ProcessFlow Integrator (PFI).

The scenario is the following. We have a workflow where approvers need to review certain information and take action, for example Approve or Reject. In this particular scenario the buttons to approve and reject are embedded in the email such that approvers can take action directly from their mailbox, i.e. we are not discussing the scenario of the Inbasket in Lawson Smart Office (LSO).

I call this the Mailbox Inbasket.

Note: The reason to use emails instead of the Inbasket is that not all approvers use LSO, for example in certain companies the managers don’t use LSO, they just have a mailbox. The other advantage of using the mailbox instead of the Inbasket is that taking action from the mailbox works from virtually any mail client that has network access to the PFI server, from corporate mobile phones for example.

When the approver takes action (for example Approve or Reject), PFI will challenge the user for authentication. The approver enters the login and password, PFI validates the credentials, and carries on with the action (Approve or Reject).

The problem arises if the user forwards the email to another person, the parameter RDUSER embedded in the URL could lead to impersonation, i.e. a user could take action in place of another user. That’s not desirable.

To avoid impersonation, we must remove the parameter RDUSER from the URL. But in doing so, PFI will throw an error.

The solution I propose is to create an intermediate JSP that will append the parameter RDUSER to the URL only after authentication.

I call it myinbasket.jsp.

Create a JSP file with this line:

<% response.sendRedirect("/bpm/inbasket?" + request.getQueryString() + "&RDUSER=" + session.getAttribute("com.lawson.bpm.webcomponents.userId")); %>

Place that JSP in the bpm.war folder in WebSphere.
Remove the parameter RDUSER from your trigger URL

Then replace inbasket by myinbasket.jsp in your trigger URL. For example,
from:

[...]/bpm/inbasket?FUNCTION=dispatch[...]

to:

[...]/bpm/myinbasket.jsp?FUNCTION=dispatch[...]

The JSP will dynamically get the userid of the user that just authenticated, will append it to the URL, and will respond with a location redirect.

That’s it!

Mailbox Inbasket for corporate mobile phones

Here is a video that illustrates we can use the mailbox of mobile phones to take action in the Inbasket of ProcessFlow Integrator (PFI). The video is a working demo for the BlackBerry and dates from September 2009, but the concept is still valid today and could apply to iPhones and Android devices as well.

The reason to use emails instead of the Inbasket is that taking action from the mailbox works from mobile phones that have network access to the PFI server, such as corporate mobile phones.

An alternative to the mailbox for corporate mobile phones would to use the Mobile Inbasket.

Finally, the demo in the video challenges the user for authentication, but there is also a solution with single sign-on to skip the user/password part.

If you are interested in the solution, contact me for details.

Here is a screenshot for an iPhone:

Solution to avoid the Invalid login request in PFI

In the PDF paper Solution to avoid the Invalid login request I propose a solution to repeatedly trigger ProcessFlow Integrator (PFI) flows while maintaining authentication and while avoiding the error: “SecurityAuthenException: Invalid login request. You are already logged in and have a valid session”

How to customize the result of a ProcessFlow Service

In the PDF paper How to customize the result of a ProcessFlow Service I explain how to customize the content-type of a ProcessFlow Service trigger and propose different output formats depending on the user agent. The output could be a user-friendly HTML page for colorful reading, plain text for simple emails, or XML for post-processing in scripts. The reader could use this technique to produce other content-types such as Excel, CSV, PDF.

Comparison of solutions to trigger PFI flows

Here is a quick comparison of various solutions to trigger ProcessFlow Integrator (PFI) flows:

Technique	Manual, Automatic, or Scheduled?	M3 modification free?
M3 Java modification with MAK	Automatic	No
Application Messages in CRS420 (for existing messages)	Automatic	Yes
Application Messages in CRS420 (for new messages)	Automatic	No
Script in Smart Office (old technique)	Manual	Yes
Script in Smart Office (new technique)	Manual	Yes
External Program Connector (EPC)	Automatic	Yes
PF Scheduler	Scheduled	Yes
URL (email, browser, XHR, Document Links, LSO Shortcuts, etc.)	Manual	Yes
Mashup	Manual	Yes
Field Audit Trail	Automatic	???
Event Hub	Automatic	Yes

Trigger PFI flows via EPC

As a reminder, there is a solution to trigger ProcessFlow Integrator (PFI) flows using External Program Connector (EPC) to avoid modifications to M3.

One traditional solution to trigger PFI flows from M3 is to make small modifications to the M3 Java source code with MAK. It only takes a few extra lines of code to trigger a PFI flow when an event happens in M3, for example when a new Customer is created in CRS610 or when an Item is changed in MMS001. But this solution is intrusive as it requires a modification to M3 which we strive to avoid to minimize maintenance.

Instead, we could use EPC. EPC is a reverse API where M3 sends XML messages to EPC on events such as Create, Change, and Copy. For that, we setup a Subscriber in EVS040, a Remote Server in EVS038, and a Subsystem Job in MNS051. Then we develop an EPC plugin in Java, outside of M3, to process the XML messages and to trigger the PFI flows. This new solution is non intrusive as it avoids modifications to the M3 source code. However, it requires the configuration of several M3 programs and the development of an EPC plugin in Java.

If anybody is interested in the EPC solution, please contact me for details.

Note: There is also a solution to trigger FPI flows via Field Audit Trail.