As they say, "wonders never cease", or something like that. In last month's LawsonGuru Letter I asked for your feedback on how well you think Lawson Support is working for you.  And, just as I'm compiling your comments, I need to check something on support.lawson.com for a client, and this is my greeting:

 

Clearly Lawson is experiencing on-going growing pains, but this is not an isolated incident:

• http://blog.lawsonguru.com/2008/04/29/whos-minding-the-store/
• http://blog.lawsonguru.com/2007/10/22/now-not-serving-number/

And hopefully Lawson's new CIO will get right on it.  But in the meantime, you've got a business to run.  And that depends on Lawson's support site being available to you. And getting good, solid support. Here's a sampling of what you and your fellow readers had to say about Lawson Support:

• It isn't that it only seems like you only get the follow-up survey calls on cases with happy endings, it's so consistent that we're convinced that Lawson has a procedure that ensures that they only call on successful cases. I had an LIS case recently that must have fit their profile only because the support representative said the issue was not covered and abruptly closed the case. The survey taker was obviously flustered when I responded "no" when she asked if we were satisfied with the resolution of the case. She mumbled something about notifying Lawson so they could follow up but of course we never heard anything back.
• Just last week, I got a NEW Lawson person and I pretty much had to figure out my issue. They were happy I taught them!!! Ugh!!!!
• I absolutely agree with your assessment of Lawson Support. In most cases the initial support person doesn't seem to really understand what you're talking about and you generally must waste time sending them info, screen shots, datadumps etc that you know have nothing to do with your issue. I do find that once you've been "passed" 1 or more times you ultimately end up with someone decent. It's just getting through the initial frustration. Truthfully we have to be fairly desperate to consider Lawson Support and have generally pursued every possible angle on our end before contacting them.
  
  The other most common frustration is the "you're the only client who has this issue" even if true - So What!! We pay for support for a reason.
• I find that the follow-up calls seem to only come on cases resolved in 1 day. Any of the real meaty troublesome issues that go on endlessly while they try to tell you "working as designed"--you will never receive a follow up call.
• I completely agree with you regarding GSC support. My personal experience has been very frustrating especially when dealing with the first tier support, which is normally the case. They usually do not read the complete description of the issue which states that I have already done most of the preliminary legwork and the obvious regarding the case I am reporting.
• I would concur with your assessment. I can almost predict when my calls will be going into the "LIS black hole".
  
  There are other times when my calls get threaded up through the appropriate channels and are resolved. 9 times out of 10 those are the times I get the service evaluation calls.
  
  Approximately 2 years ago, I called our CAM with a complaint about a CTP that I had a quality concern about. He arranged a conference call with 2 manager of differing GSC support areas; MM and HR. Not sure why he involved MM since it was related to HR. During the call, they played the part and suggested I introduce myself to them at CUE. After meeting the MM person at CUE, I have dubbed him "spawn of Satan". He was extremely rude and suggested we wouldn't have had an issue if we took every CTP that came along.
• Like you mentioned in your newsletter, some cases have good outcomes, some not so good:
  
  
  • We had a case that took over 4 months to resolve and each month we had a different 'caseworker' working on the problem. It was a very frustrating experience because I had to keep reminding them that we had a critical issue open and needed it resolved. And if you took vacation or were away from the office and didn't respond within the 72 hours they were waiting on a response, they closed the issue. The situation was that when we tried to insert a job change with an effective date prior to a later dated pay change the salary history was deleted. When we tried to fix it, it duplicated the salary history fields multiple times and it couldn't be cleaned up. They could not duplicate the issue but after many questions about what version we were on and which patches we had loaded, they finally came to the realization that we were not using the annual hours field and when annual hours were populated, the issue did not occur. I strongly requested that they document the issue so that other users that may run into the problem wouldn't experience a 4+ month delay in solving the problem.
  • On another case, we submitted a problem in August 2007 and they were able to duplicate a salary history correction effective date problem within 3 days and wrote up the PT issue. The fix was available with the CTP history correction patch that was released this past March.
• Oh, we’ve started to write down our favorite Lawson support sayings:
  • "I can't support your upgrade between those hours, I swim between 5-6"
  • "I wouldn't advise you touch that feature"
  • "I have no idea what they are doing...I'm just the middleman"
• Lawson advertises a customer satisfaction rate with LIS of 95.82% presumably based on the survey calls. We figure that our actual success rate is somewhere around 50% and that is probably high because we only open cases when we think there is a likelihood of success or when we are desperate.
  
  Another annoyance is their claim that the LIS response rate is 91.39% of calls answered within 120 seconds. What good is that if the response is an automated reply that says "Hi, my name is Joe Rep. Welcome to the Lawson Support Center. I will be reviewing the information you sent and reply to you shortly." And then the next message is "I will be forwarding you to the next available Support Engineer. You will receive a response within the next 2-4 business hours."

At the core of integration with your Lawson applications is the need to extract, as well as update, data. In this installment of our ProcessFlow Integrator article series, we’ll look at the Query (DME) node, which you use to retrieve Lawson data in ProcessFlow.   A future article will explore the Transaction (AGS) node, which you use to update Lawson data.  Both nodes are available with all editions of Lawson ProcessFlow.

 The Query Node (DME)

The Query node retrieves data, using Lawson’s DME (Data Mining Engine) component, against your Lawson tables and application forms, and returns the results as an array of JavaScript variables.  In the context of a flow, the query is represented as a loop, where each record and field can be examined in turn.  For example, this flow executes a query against the CURELAT currency relationship table.  For each record returned, a currency conversion rate is retrieved via a web service lookup, and the conversion rate is added to the Lawson CU10 form:

 

When you drag the Query node onto your flow, the empty box is where you need to insert the DME string:

 

If you’re not familiar with DME, it’s used extensively throughout the Lawson S3 products, including the Excel Add-Ins Query Wizard and the Lawson OLE DB provider included with Lawson Business Intelligence.  DME essentially operates like a SQL SELECT statement, but with its own unique syntax.  By the way, DME enforces Lawson security (either LAUA or the Lawson 9.0 Security).  Keep in mind, however, that once your ProcessFlow flows are deployed to the server, they are run using a common RM ID, generally one with wide-open security.   In other words, if you building a flow, you should be doing so with a similar RM ID.

If you click the ‘Build’ button, the ProcessFlow IOS API Builder (essentially a Wizard for building your DME string) will be displayed:

You can either query against a database table or an application form, so the first thing you need to do is select the DME String Type:

You then drill into the desired object (the database table or application form) by double-clicking the desired product line, system code, and object; and a list of fields on that table or form will be displayed:

 

Fields from Related Tables

When querying against database tables, you can also select fields which are in related, rather than the primary, table—provided that a relationship is  defined within Lawson’s data dictionary.  Click on the ‘Relations’ button, and a list of related tables will be display:

When you select field(s) from related tables, they are displayed in the list of selected fields, prefixed by the relationship name (which is not necessarily the name of the related table):

Specifying Criteria

Once you’ve selected the desired table/form and fields, you can use the ‘Criteria’ tab to limit what is returned.  Depending on whether you’re querying a form or a table, you will see a different criteria form; for tables, you can specify which index (and corresponding values) are used to limit the data being returned in the query:

For an index, you:

• Select the index to be used (on the left)
• Select each field (within the selected index) for which you want to specify criteria values (in the middle)
• The actual values you want to specify for each index field (on the right)

For index values, you:

• Indicate a range using the a “poor man’s arrow” (a dash and greater-than sign), e.g. A->B
• Specify a list by separating them with a semi-colon, e.g. A;B;C
• Also, be aware that you must specify index key values “from the top down”.  In other words, you can’t specify the second field in an index without specifying the first.  For example, you can’t specify a value for FR-CURR-CODE without also specifying a value for CURRENCY-TABLE:

You can also specify selection criteria (which since it doesn’t use an index, is slower):

 

Finally, for database tables you can also apply ONE record condition, selecting from those defined in Lawson’s data dictionary:

DME returns data in a variety of ways, including as delimited records.  For ProcessFlow, you need to return it as tilde-delimited:

Once you’ve specified your fields and criteria, you can test the DME string, which will access your Lawson applications, and return a sampling of data:

Click the Copy API button (this is a VERY important step—if you don’t click “Copy API”, and you close the API Builder, you’ll have to start over!).

Paste the DME string back into the Query Node:

 

Note that the Product Line you select in the API Builder doesn’t necessarily have to be the same Product Line that is used when the flow is executed.  Within every ProcessFlow flow, an appProdline variable is populated, and therefore can be used to ensure portability of your flows between development, testing, and production, etc.  In other words, don’t hard code the Product Line via the PROD=xxxx portion of the DME string—use the appProdline <!appProdline> variable:

A few more things to note about the Query node:

• You can specify a Caption and Name field. Using a descriptive value for each will greatly aid in your ability to document and understand your flows.
• You don’t specify the server and/or protocol as part of the DME string. That is inserted automatically. ProcessFlow supports both HTTP and HTTPS.
• There is a ‘Stop process on zero records’ option for the Query node; if you select this option and your query does not return any records, the flow simply stops.

Using the Query Output

Now that you have a query, and it returns output, you need to be able to use it. Remember that in ProcessFlow, you fasten together a collection of “Activity Nodes” to orchestrate a business process. Activity Nodes are connected together to represent logic; each Activity Node can use the output of previous Node(s) as its input (i.e. that’s what makes up the “flow”). And, that’s how you use the Query node. Its output (i.e. the DME results) is returned as JavaScript variables.

Using the name you specified for the Query Node (i.e. qryCU in this example):

ProcessFlow creates variables—for each field returned in the query—and exposes them to all subsequent nodes in the flow:

By the way, now that you’ve seen some different ProcessFlow nodes, you’ve probably noticed that ProcessFlow uses different syntax for the variable names:

• ProcessFlow variables are defined using an exclamation point (!) and angle brackets (<>), so that EMPLOYEE.FIRST_NAME returned from Query node called “qryEmps” becomes <!qryEmps_FIRST_NAME> when used within a non-JavaScript node, like MsgBuilder.
• However, for nodes that use JavaScript, the exclamation point and angle brackets are dropped, and it’s simply qryEmps_FIRST_NAME.

And then just to confuse you, some early LSF9 releases of incorrectly returned the variable names from related tables as qryName_RELATED.FIELD_NAME rather than as qryName_RELATED_FIELD_NAME; the “.” in JavaScript denotes an object property and this would return an error. Thankfully Lawson has fixed this in recent LSF9 releases.

In the Loop

By inserting and connecting nodes within the Query node loop, you can use the variables returned from each record to perform other nodes:

 

Nested Queries

You can also nest Query nodes, so that the output of one query is used as the input criteria of another query.  For example, one query could retrieve a list of supervisors, and then a second query—executed for each supervisor returned in the first query—can query for that supervisor’s direct reports:

 

Six Sigma: Uncovering Hidden BI Assets

Six Sigma BI is a customer-focused, metrics-based approach that refers to a better and smarter way of creating and managing BI assets.
BI Review, April 10, 2008
http://www.bireview.com/bnews/10001126-1.html

How To Choose Among The Four Bright Lights Of BI

IBM, SAP, Oracle, and Microsoft account for about half of the $7 billion business intelligence market. All four are pitching enterprise-wide BI platforms, each with its own twist. Here's what you need to know to choose.
Information Week, April 14, 2008
http://www.informationweek.com/news/business_intelligence/information_mgt/showArticle.jhtml?articleID=207101021

Auditor Angst

- QUOTE OF THE ISSUE –
“The wisest mind has something yet to learn.”
-- George Santayana

Want faster, cheaper audits? Your auditor humbly suggests you avoid last-minute data dumps and other less-than-helpful practices.
CFO Magazine, May 2008
http://www.cfo.com/article.cfm/11078678/c_11081639

What If Yoda Ran IBM?

The big vendors beat down the doors of large companies to get business, but a small-company CIO gets the brush-off. He wonders how to harness the powers of the Force, and get some big-company expertise to help the little guy.
CIO Magazine, March 15, 2008
http://www.cio.com/article/162450

Base Binary/Decimal/Hex Converter

On Windows, Lawson stores three key elements related to user IDs:

• Windows SID is stored in registry in v7/v8 Environment; in Lawson's LDAP in LSF9
• As NTxxxxxx in GEN security tables
• As a numeric User ID (UID) in LSF9 in Lawson's LDAP.

Lawson uses a base-10 to base-16 conversion routine to map an NTxxxxx ID to the UID. I wrote a JavaScript function for doing this in ProcessFlow, creating a simple conversion table.  But I also find myself occasionally needing to manual convert from the numeric UID to NTxxxxxx and vice versa. Here's a handy website you can use to handle the conversion: http://www.csgnetwork.com/basexcnv.html