MOCA COMMAND OVERVIEW

 MOCA Command and Component Details

> A MOCA command can invoke a component written in MOCA 

Local Syntax, C, or Java.

> A MOCA command written in MOCA Local Syntax can also 

invoke the Groovy scripting language.

> MOCA Components always consist of a MOCA command file 

stored in directories at various levels on the WMS server.

> When a MOCA Command is invoked, the MOCA architecture 

starts at the highest level of customization and then works down 

to find the correct MOCA command to execute.

> MOCA commands are named using a Verb/Noun combination to 

describe what action or service they provide.

Some examples of names used for MOCA commands in 

WMS include:

> allocate inventory

> create order

> list inventory details

• Note that we have one Verb indicating the action 

followed by 1 or more Nouns to show what we are acting 

upon.

• For custom MOCA commands, we add a 'var' or a 'usr' 

to the command name to distinguish the command as 

being custom, some examples:

> allocate var location

> produce usr pallet label

• Arguments are passed when invoking the command in 

this fashion:

> list inventory details where wh_id = 'WMD1' and prtnum = 

'tstpart' and stoloc = 'CASERACK2001'

• The flexibility of MOCA is that we do not have to always 

pass every argument into a command.

• We can call some commands without any arguments 

and we can also setup commands to default a argument 

if something is not passed in.

Transactional integrity is part of the MOCA Component 

architecture.

• A MOCA command is considered a "transaction" and if 

any error occurs, the entire command is rolled back.

• If the MOCA command is successful, commits are 

automatic.

• The client does not have to do any commits or rollbacks.

• The client only needs to handle the error code being 

returned and display a message or take some action on 

the error.

 MOCA Level Hierarchy continued…

• This Hierarchy means that if we create a custom command with the 

same name as a command in the standard product directories, our 

custom command will "override" the command if we put it at the 

VAR or USR level.

• The %LESDIR%\varint directory is where we place most custom 

MOCA commands and is at the VAR level.

• The %LESDIR%\usrint directory is where we ask users to place 

their custom commands and is at the USR level.

• By keeping the customization at those levels, it is much easier to 

track the custom changes on a project.

 How are the MOCA command levels are defined?

• For each MOCA command level we must have a directory under 

%LESDIR%/src/cmdsrc and a matching .mlvl file.

• For example, for the MOCA command level varint, we have the 

%LESDIR%/src/cmdsrc/varint directory and in 

%LESDIR/src/cmdsrc we have a varint.mlvl file.

<component-level>

<name>VARint</name>

<description>VAR Intrinsic Server Functions</description>

<library>VARint</library>

<package>com.redprairie.les.intrinsic</package> 

<sort-sequence>8000</sort-sequence>

<editable>true</editable>

</component-level>

How are the MOCA command levels are defined 

continued…

• The name must match the directory name in the file system.

<component-level>

<name>VARint</name> This is the name of the level

<description>VAR Intrinsic Server Functions</description>

<library>VARint</library>

<package>com.redprairie.les.intrinsic</package> 

<sort-sequence>8000</sort-sequence>

<editable>true</editable>

</component-level>

How are the MOCA command levels are defined 

continued…

• A library name is given if we are developing MOCA commands that 

invoke a C component at this level.

<component-level>

<name>VARint</name>

<description>VAR Intrinsic Server Functions</description>

<library>VARint</library> C shared library or DLL name

<package>com.redprairie.les.intrinsic</package> 

<sort-sequence>8000</sort-sequence>

<editable>true</editable>

</component-level>

 How are the MOCA command levels are defined 

continued…

• A package name is given if we are developing MOCA commands 

that invoke a Java component at this level.

<component-level>

<name>VARint</name>

<description>VAR Intrinsic Server Functions</description>

<library>VARint</library>

<package>com.redprairie.les.intrinsic</package> Java Package Name

<sort-sequence>8000</sort-sequence>

<editable>true</editable>

</component-level>

 How are the MOCA command levels are defined 

continued…

• The sort sequence defines the level priority.

• If two or more commands are found with the same name, the 

command at the level with the higher sort sequence will be 

executed over the command(s) at a lower sort sequence level.

<component-level>

<name>VARint</name>

<description>VAR Intrinsic Server Functions</description>

<library>VARint</library>

<package>com.redprairie.les.intrinsic</package> 

<sort-sequence>8000</sort-sequence> This is the sort sequence

<editable>true</editable>

</component-level>

 How are the MOCA command levels are defined 

continued…

• The "editable" flag determines whether we can edit this command in 

Server Command Maintenance in the GUI.

<component-level>

<name>VARint</name>

<description>VAR Intrinsic Server Functions</description>

<library>VARint</library>

<package>com.redprairie.les.intrinsic</package> 

<sort-sequence>8000</sort-sequence> 

<editable>true</editable> Controls editing in Server Command Maintenance

</component-level>

MOCA Triggers

• We can also define a special MOCA command called a MOCA 

Trigger.

• MOCA Triggers "fire" when a MOCA command completes.

• There can be more than one trigger called from a MOCA command, 

the order is determined by a sequence defined in the trigger.

• A failure in the trigger will also rollback the command the trigger is 

associated with.