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.

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.

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.

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:

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.

Background

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.

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:

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.

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.

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.

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 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).

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.