Monday, 15 July 2013

Eight things every developer needs to know about SYSPRO

Syspro is highly customisable and extendable using programs you can write in C# or VB.Net, VBScript, or using web services, workflows, you name it, but there are some key things you need to know about.

1. Where does Syspro run VBScripts?

Syspro has an in-built VBScript engine that allows Syspro administrators to add custom functionality on to Sypsro. There are a few things that are useful to know about SYSPRO's VBScript engine.Firstly, it's important to know where your VBScripts run: either on the server or on the client.

VBScripts as code behind forms

VBscripts that are placed in the code behind your forms run on the Syspro client; these are triggered from user-interface events such as a form's OnLoad event or a field's OnLostFocus event.

Electronic Signatures

VBScripts that are triggered from Syspro's Electronic Signatures are run on the Syspro server.

Event Management

Event Management events are executed on the server.

Trigger Programs

Trigger Programs run other Syspro programs, but do not fire VBScripts directly themselves. They run on the client.

2. What companies are affected by a VBScript?

When you install a VBScript in SYSPRO, it applies to all companies managed by that server.
This can trap unwary users! Be warned: even if you have a test company and a live company and you install your VBScript in the test company, it will affect the live company immediately!

The correct way to handle this is to have a totally separate SYSPRO server for development and testing.

Also, you can easily limit your VBScripts to a particular company with code that uses the Company system variable, such as this example, where "T" might be the company you use for your test company:

if SystemVariables.CodeObject.Company = "T" then
    <your code>
end if

or more simply:

if SystemVariables.CodeObject.Company <> "T" then exit function

3. What users are affected by a VBScript?

When you create a VBScript, that VBScript will not only affect all companies; it will also affect all users, not just the user that created the VBScript. In other words, the script is a system-wide VBScript.


However, if you are using Roles, you will have a choice whether to edit the system-wide VBScript, or to create or edit the VBScript that will just affect the users of that Role. This is the correct method to use to limit a VBScript to one or more users.

4. What users will see changes to a menu or pane?

If you move fields around on a pane, or change their Field Properties (font, colour etc.), then only the logged-in user will see those changes next time you log in again, and you will only see them on the same computer that you logged in on, i.e. if you log in on another computer as the same user, you won't see those changes. This is because the changes are recorded in local .DAT files; these files are not copied up to the server and distributed to other computers.

However, if you are using Roles, then all people in that role will see the changes. The changes are again stored in local .DAT files, but they are copied up to the server and distributed to other users of that role.

5. What users will see new custom or scripted fields?

If you create a new custom or scripted field and add it to a pane, all users will see it on their pane.

6. Where does Syspro run reports?

Syspro runs reports using SRS, aka. Syspro Reporting Services, which uses Crystal Reports at its core.
Custom-written reports are run on the Syspro CLIENT, in Syspro 6.1. This is the case, in Syspro 6.1, regardless of which communication method you are using: Syspro Communications Service (which is built using WCF) or the CCIT communications service.

I don't yet know where STANDARD (i.e. not custom-written) Syspro reports are run, although I suspect they're run on the client.

I suspect that in Syspro 7, reports will be run on the server, but this is yet to be confirmed.

7. Where does Syspro run Workflows?

Syspro workflows can be started by a VBScript on the Syspro client, but the workflow itself runs on the server.

8. What configuration files does Syspro use?

IMPWRK.INI

On the client, when you log in, the IMPWRK.INI file is first read from the same directory that the Syspro executable file is stored in. So if you run C:\Syspro61\BASE\IMPCSC.EXE, then the first configuration file read will be C:\Syspro61\BASE\IMPWRK.INI.

IMPACT.INI

IMPWRK.INI points to a second file, IMPACT.INI, which is usually kept in C:\Syspro61\WORK\IMPACT.INI.

Sysprodb database

Syspro keeps its data in Microsoft SQL Server a database, and it has a master database, SysproDb, that it uses to map each company to its database.

ADMOPR.DAT and other *.DAT (and their *.IDX) files

Syspro keeps its list of operators in the file, ADMOPR.DAT and its associated index in ADMOPR.IDX. These two files are kept on the Syspro server, but they are copied down to the Syspro client when the client logs in.

Other .DAT files are copied to the Syspro client at log-in as well. See the tables below for more information.
The .DAT files are C-ISAM files.

Filename prior to and including Syspro 6.1
Where kept
Description
Where the information is kept in Syspro 7
ADMLSR.DAT (.idx)
Client
List view layouts and settings file
List_operator_listviewName.XML
ADMLSD.DAT (.idx)
Client
Docking control layouts
Dock­­_operator_dockingName.XML
ADMLST.DAT (.idx)
Client
Form settings
ADMLFR.DAT (.idx)
ADMPRO.DAT (.idx)
Client
Form caption sequences
Form_operator_formName.XML
ADMLAY.DAT(.idx)
Server
List view, docking, form and customized pane layouts for roles
…\settings\role_nnn\
List_name.XML
Form_name.XML
Dock_name.XML
Pane_name.TXT
ADMPRO.DAT (.idx)
Server
Group and Company caption layouts
Form_Group_group_formName.XML
Form_Company_company_formName.XML
ADMOPR.DAT (.idx)
Server
List of Syspro Operators
ADMOPR.DAT (.idx)




Monday, 8 July 2013

How to configure SQL Server for SYSPRO

These instructions apply to SQL Server 2005 and later, including SQL Server 2008 R2, SQL Server 2012, and SQL Server Express versions.

Set Collation Order

The collation order for a SYSPRO database MUST be case-sensitive; the recommended collation order is Latin1_General-BIN. Normally you would set the database server's default collation to be this order, but you can set it at the individual database level by creating a new database and setting its collation order; you must do this BEFORE you get Syspro to populate the database with tables etc.



Set Mixed Authentication Mode

Your SQL Server should be set to SQL Server and Windows Authentication mode in your Server properties.


Database Usage

The Compatibility level of your database must be set to SQL Server 2005 or later; SQL Server 2000 is not supported by Syspro.

See this document for more details: SQL Server Tricks and Best Practices.pdf

Set Desktop Heap size on the server

If you have a large number of users, you should increase your desktop heap limit on the Syspro Application Server. See this post on the Syspro Forum for more details.

Friday, 5 July 2013

How to test your Syspro Communications Service

These are some basic tests you can use to check if Syspro's Communications Service is up and running.
  1. Can you ping the Syspro server (provided the Syspro server responds to ICMP ping requests)?
     
  2. Telnet to the server and port, then hit ENTER a few times, e.g.

    telnet example.com 1998

    If you get this:

    Connecting To example.com...Could not open connection to the host, on port 1998: Connection failed

    then you didn't get a connection at all. This could happen if you had the wrong port or IP address.

    However, if you got a clear screen, then when you hit ENTER the telnet session terminated, then you got a connection OK.

    "Actively refused" means that you got at least as far as a TCP Connect packet arriving at the named server.
     
  3. From an elevated command prompt (i.e. run CMD as Administrator), run this command:

    netstat -ano | findstr 9999

    where 9999 is the process number or port number you are interested in.
    You should see your process and port listed.
     
  4. Check the Event Log for any error messages: in the Event Viewer, look under Application and Services Logs / SYSPROCOMMS.

How to launch a Syspro report from VBScript and pass it parameters

One way to launch a Syspro report from a Syspro client-side VBScript is to create a new custom pane in an empty AppBuilder program (e.g. IMPDH1). Set the custom pane's Object Type to SRS/Crystal report, and enter a Report file name.

Then launch that AppBuilder program from your VBScript.

To pass parameters to your report, place your parameters in a custom table in the database, and read those in your report.