Introduction to MOCA Client by Smart IS

Working with the Blue Yonder (BY) WMS application can take on many roles. Your relationship with it could be that:

• You are a general user that primarily interacts with the application through the provided screens and navigate using the menu options.
• You are super user and often end up using the “Server Command Operations” to do simple SQL statements or run commands.
• You are a super user cum developer who is tasked to do some DDA development, labels, reports etc.
• You are a developer doing development in the application; development can be around MOCA Commands, DDAs, Reports, Labels, RDT Screens etc.
• You are a support person that needs to investigate traces, run commands, run SQL statements to do root cause analysis.

Other than the first role mentioned above, your role demands interaction with the BY WMS application at a command/ SQL level ;and unfortunately, you find out very quickly that the available toolset is limited. The following are the tools provided by the vendor:

• Server Command Operations (going obsolete in the newer version)
• WinMSQL

For SQL access, you can rely on tools/ consoles available from the database vendor, but then you are limited to executing SQL only and no MOCA commands can be executed.

The shortcomings of Server Command Operations and WinMSQL are many but take a look at a few below:

• Server Command Operations is limited to one window (unless you launch multiples from the menu) and the result set is always with the dictionary embedded. Meaning you cannot see the raw column data if you wanted to or the column names.
• Server Command Operations does not have any syntax management, so it is a difficult user interface for larger command sets.
• Server Command Operations must be run from within the GUI Application.

WinMSQL overcomes some of the shortcomings mentioned above, but it is a dangerous tool as it has no management controls (like security control as to who can run it).

· WinMSQL only allows access to MOCA Commands and SQL. It does not help around the file system access, or aid in the development of commands.

Thus, both the Server Command Operations and WinMSQL are user tools for helping in troubleshooting but cannot be utilized as development tools. This means a typical developer is resorting to:

• Utilize Server Command Operations or WinMSQL for prototyping the SQL or the MOCA Command
• Using a Text Editor to put together the command (locally or directly on the application server)
• Using FTP or other file exchange protocol for copying a locally developed command to the Application server
• Running MBUILD on the server by connecting to the Application Server
• Doing a Bounce (or Reload Memory) using the Console application
• Testing the command through Server Command Operations or WinMSQL

Depending upon the Application Server, there are limitations for the developer in their ability to access the server for their development:

• If it is Windows based, they need to access via RDP, which limits the number of users that can connect at the same time.
• If it is Unix/ Linux based, then the developer should know how to navigate that landscape and be comfortable with editors like “vi”.

This preamble helps us appreciate the challenges developers face. Combined with the increased complexity of Application Server Management access as mentioned above, the development life-cycle can be quite demanding.

One can discount this by taking the position that a) development is only in the beginning or the project is limited in scope, and b) a developer should know what they are doing and hence be comfortable with the challenges mentioned. I can agree to this, however, as mentioned in the beginning, the super users in many organizations are becoming developers, and development continues after the initial implementation as users become more comfortable with the available data and want to have better access to it and want to build KPI engines etc.

Welcome to Smart-IS’s MOCA Client!

Smart-IS realized this challenge for its developers very quickly. We identified that our developers need to be empowered with a development tool that can overcome the shortcomings mentioned above while respecting the challenges that each client’s infrastructure landscape may present and remain as immune to it as possible.

Our goal in realizing the MOCA Client was:

• Single tool/ interface for development, prototyping, troubleshooting and building applications
• Provide development aids as needed to enhance the developers experience
• Provide access to the Application Server through MOCA layer to avoid the need for accessing Application Server directly
• Build Change Management into the DNA of the application so this tool can face any Audit Challenge

This vision of MOCA Client (which continues to evolve as new ideas are imagined) allows for the following key features to be available in the tool:

• Execute MOCA, SQL and OS Commands from one place
• Multi Tab/ Sub-Tab user interface
• Respects Security setup of the application, requiring the user to have “Server Command Operations” access to be able to use the MOCA Client
• Further Security can be added using MOCA Registry Tags
• Access to the Operating System files, through the MOCA layer. This is irrespective of the Host operating system
• Ability to move files to the host or download from there
• Integrated Tracing and a better Trace Viewer than the JDA’s standard offering:

Trim Trace files for RDT Traces to remove unneeded trace messages

Calculate Execution times for commands from the trace file to better understand performance

Load trace files into database (especially useful for larger trace files)

• Tools to find files, find with a given text or without some text, and enhance the search with REGEX
• Search database entities like Policy, and Integrator tables
• Find Differences:

between environments at File or Data Setup level

between 2 files

between database tables and columns (at DDL level)

between Integrator Transactions

· Move data and files easily from one environment to another by building rollouts

· Manage DDL objects (creating tables, indexes etc.) through the tool by running the INSTALLSQL Macro on the Application Server

· Integrated Change Management. This allows that if the Client has enabled Change Management, then a developer cannot make changes to any files unless assigned a Change Request number.

· Develop DDA directly from this tool

· Develop RDT Applications from this tool

· Launch MOCA Console from this tool

· Manage and generate Test Data (if Automated Testing is installed)

· Enable Macros to do command sets easily

· Automatic Command Completion

· Automatic Database Table Names completion

· Automatic Column Name completion

· Ability to auto-populate Command Arguments

· Ability to designate an Environment (like Production) to be a sensitive environment requiring extra confirmations on Create/ Change/ Remove type commands

· Maintain history for each environment of all commands executed. This alone helps in passing many Audit Concerns

· Emulate Zebra Printer to view a POF file results

· Emulate a Socket for testing Socket Interfaces

· Run MLOAD directly from this tool

· Generate Control Files for a Table or based on a CSV

· Load CSV Locally into the tool and then manage it to build a result set or insert/ update statements that can be executed in another environment

· Save Local Scripts (the tool comes pre-loaded with many useful scripts)

· Ability to execute scripts on Timer

The list of features mentioned above is ever-growing. A new version of the tool is launched every two-three months based on feedback received from our developers and user community at large.

The tool is free to use. You can download it here.

We advise to download the latest version. Instructions and how to install it are available once it is downloaded and installed.