Programming

Flow Script

Flow scripting is necessary to use for processing data when you work with “non-deep" connectors like REST/SOAP, MAXIMO, MS Dynamics etc. See further script examples in the Flow Help.

Machine Step

Script Outputs

When working with Connector Type "Database" machine steps, it is possible to get the outputs of the executed script assigned to the Target Variable of the machine step. The Target Variable field would be disabled for Database Call Type "Script" machine steps by default. To activate this field, first you need to define the output variables in side code.

A good example would be if you are creating a Purchase Order using a script, you will need the created PO No extracted to inform the customer of the new PO. This can be done only be defining a "out" variable at the end.

In PL/SQL scripts, out variable needs to be defined starting with a ":" symbol where as for T-SQL scripts, out variable needs to be set starting with a "@" symbol.

PL/SQL

BEGIN
  ...
  ...
    
  :out_OrderNo := order_no_;
  
END;

T-SQL

BEGIN
  ...
  ...
    
  SET @out_OrderNo = @OrderNo;
  
END;

Iterator Option

A full iteration (all included records) is processed as one database transaction, and COMMIT is executed at the end. An error raised on any row causes a stop and rollback of the whole database transaction.

An exception should be defined to handle any error in the processing of a record. This is usually at the end of the code written for processing each record. This allows for processing all rows even if a single record fails.

Output from the iteration is a flow table which can be used for returning values/results for each row in the iteration.

All data must be stored in database tables in order to communicate between iterations.

If any additional database operations are needed during executing of first/last row, adjust the data set to add two new columns like "RowNumber" and "NoOfRows". The iterated data set can be adjusted, using flow script, before it is processed.

For CRUD workflows, a variable "Type” (with values add, update, delete) is used to distinguish operations. Recognize the appropriate value to handle records in a table.

Oracle PL/SQL

Use of IFS Application Owner

All views and API calls used in Machine Steps needs to be prefixed using the application owner in order to flow to work. Usually "IFSAPP" is the application owner, making our code logics looking like below example.

However, if the customer wishes, they can change the application owner account to a different user other than IFSAPP and disable the IFSAPP account for security reasons. If this happens, all developed flows using IFSAPP will stop working. Further, if you are planning to develop a flow as a template, it should have the ability to work for any support any application owner setup. This needs to be achieved by defining a Global Variable to enter the application owner and using that parameter as the prefix inside the code as shown on below screenshots.

Environment Properties Setup for AppOwner Variable

Assigning the Global Variable to a Flow Variable at Beginning of the Flow

Using AppOwner Variable in the Code

AppOwner cannot be called as :AppOwner in view/API prefixes. It has to be done as {AppOwner}.

What to Do

Define variable names with underscore between words and at the end, i.e. customer_order_no_

Use proper indentation when you write your statements.

Always use database values or decode/encode instead of client values in where conditions. Otherwise the flow may fail when using with a environment using a different language as the default language.

Using Database Values

Every time use ONLY API calls New, Remove, Modify methods or any other IFS pre-defined methods. Never use data insert, update, delete statements.

Example for using Remove method to delete handling units

All views and API calls used in Machine Steps needs to be called using the application owner in order for the flow to work. Usually "IFSAPP" is the application owner. However there may be a different application owner. Hence always use a global Flow variable (as shown above) to set the application owner.

What to Avoid

Do not just copy the variable names (p0, p1, p2, p3, etc) from IFS debugger. Use variable names matching to IFS backend column names for uniformity and easy identification.

Never use Commit. Flow does it when exiting a Cog Wheel.

Never use Tables (_TAB) to select data. Instead, always use views to get data.

Microsoft TSQL

To differentiate values from flow variables, use @c_ to indicate that a value is a locally declared variable within the cogwheel.

When writing data (Database Call Type: Script), NULL values can cause an issue since flow does not really handle NULL. A way to solve that is to use the following code for all your variables thtat might come as NULL.: if len(@Variable) < 1 set @Variable = NULL for all your variables that might come in as null.

if len(@Variable) < 1 set @Variable = NULL

If you have Identity enabled on a column (so that SQL assigns a seed value), you can use SCOPE_IDENTITY() to get the newly created record ID.

select @out_logid = SCOPE_IDENTITY()

To select from a stored procedure:

Declare @T Table (AddressID int, AddressLine1 nvarchar(500)) 
Insert @T Exec uspGetAddress 
Select AddressID "AddressID",AddressLine1 "AddressLine1" from @T