Thursday, 22 August 2013

How to connect to a Syspro web service

Syspro has a very powerful and comprehensive set of API's exposed as web services. Here is a guide for how to use Syspro's web services.

Firstly, you need to connect to your Syspro web service’s server and get authenticated; in return, you will get a GUID.
To do this, you need to connect to the Logon method of this SOAP service:

Then you will can call an actual API to do something useful. In this example, we will send Syspro a finished goods receipt using the Transaction web service:

To call the Transaction web service, you need to pass these four parameters:

  1. UserId – use the GUID you obtained when you logged into SYSPRO as described above.
  2. BusinessObject – set it to be this string: INVTMR. There are many business objects that you can call via the Transaction web services; consult the Syspro business object documentation on the Syspro Support Zone for what web services you can use. 
  3. XMLParameters – this will be a fairly large string containing an XML document as described below.
  4. XMLIn – this will be a fairly large string containing an XML document; see below for example.

XMLParameters

Here is an example of the XMLParameters string:
<?xml version="1.0" encoding="Windows-1252"?>
<PostInvReceipts xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="INVTMR.XSD">
  <Parameters>
    <TransactionDate>2013-08-20</TransactionDate>
    <ApplyIfEntireDocumentValid>Y</ApplyIfEntireDocumentValid>
    <ValidateOnly>N</ValidateOnly>
    <ReturnDetailedReceipt>N</ReturnDetailedReceipt>
  </Parameters>
</PostInvReceipts>

XMLIn

Here is an example of the XMLIn string:
<?xml version="1.0" encoding="Windows-1252"?>
<PostInvReceipts xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="INVTMRDOC.XSD">
  <Item>
    <Warehouse>FG</Warehouse>
    <StockCode>A100</StockCode>
    <Quantity>1.000</Quantity>
    <Reference>Receipt</Reference>
  </Item>
</PostInvReceipts>

XMLOut

On successfully calling the web service, you should get a result like this:
<?xml version="1.0" encoding="Windows-1252"?>
<postinvreceipts Language='05' Language2='EN' CssStyle='' DecFormat='1' DateFormat='01' Role='01' Version='6.1.038' OperatorPrimaryRole='   '>
<Item>
<ItemNumber>000001</ItemNumber>
</Item>
<Key>
<JnlYear>2013</JnlYear>
<JnlMonth>05</JnlMonth>
<Journal>00032</Journal>
<EntryNumber>00001</EntryNumber>
<Warehouse>FG</Warehouse>
<GlJournal>
<GlYear>2013</GlYear>
<GlPeriod>05</GlPeriod>
<GlJournal>00230</GlJournal>
</GlJournal>
</Key>
<StatusOfItems>
<ItemsProcessed>1</ItemsProcessed>
<ItemsInvalid>0</ItemsInvalid>
</StatusOfItems>
</postinvreceipts>

XSD files

There are XSD files available for each Business Object. The XSD files are distributed with Syspro and found in the <Syspro-installation-directory>\Base\Schemas directory. These XSD files can be used to generate code objects. See this blog for more information on generating code objects from Syspro's XSD files: http://phildetail.blogspot.com.au/2014/04/how-to-use-xsd2code-for-syspros.html

Monday, 12 August 2013

What LOG files does Syspro create?

Diagnosing errors can be tricky; a log file can be invaluable. Here are some log files that Syspro updates.

Log file
Description
BASE/mfdebug.log
This file gets written to when you crash Syspro; you can crash Syspro by creating a custom with a .Net User Control that throws an unhandled exception.
BASE/SRSQRT.TXT
If you create an empty file, BASE/SRSQRT.DEBUG, file, then as soon as SRS or VBScriptiong with CALLBO is used, this log file will be written to.
BASE/log.txt
If you call SYSPRO.EXE, IMPACT.EXE, IMPCSC.EXE or IMPAUT.EXE with the /log parameter, then this file will be created. It will record each time the client/server communications dialog tries to connect to the server.
BASE/settings/<operator>_RTS_ERROR.TXT
Created when there is a runtime error.
%Temp%/SYSPROCOMMLOG_*.txt
Syspro Communications Service will log files in your Temp directory (e.g. C:\Users\You\Local Settings\Temp) if you have the DetailedLog setting set to true in your Syspro Communications Service's config file, e.g. <add key="DetailedLog" value="true" /> in C:\Syspro\Syspro WCF Services\SYSPROWCFHostService.exe.config.
%Temp%/SYSPROActivityCallsLog.txt
If you create this file, the Syspro Workflow engine will log actions in it.
BASE/Settings/enetlog.dat
This log file identifies the Business Objects invoked. This file gets written to by e.Net. There are two ways to cause this file to be written to:

  1. Set the LogLevel parameter to ldDebug when you use e.Net to log into Syspro.
  2. In the Syspro GUI, go to Setup / Setup Options / General Setup / System Setup; go to the General tab and set Diagnostics to enet01.
BASE/Settings/enetlog.txt does not seem to be written to anymore, since about Syspro 6.1 SP1.

To view enetlog.dat, go to Home / Administration / Diagnostics / Diagnostics Manager (aka. IMPMON). Then go to the e.net Transaction Log tab and hit the Refresh button.

See this post for more details.
BASE/Settings/diag_xml
Xml inputs and outputs to Business Objects are logged here if the Diagnostics setting in System Setup / General is set to enetxx.
e.net Transaction Log
Go to Home / Administration / Diagnostics / Diagnostics Manager / e.net Transaction Log and hit the Refresh button.
AdmEventLog (database table)
Go to Home / Customzation / Event Management / Functions / View Log File.
AdmSignatureLog (database table)
Query this table directly in the database using SQL Server Management Studio or similar.
Job Logging
Go to Setup / Security / Job Logging. This listing includes program Logon and Logoff dates and times - quite useful.
Windows Event Log
Go to the Windows Event Log / Applications and Services Logs / SYSPROCOMMS and SYSPROSWS.
BASE\Settings\IMPUPD_Copy_Errors_*.txt
Errors encountered installing Syspro ports.
Electronic Signatures Audit Log
To view this, from the Syspro main menu, go to Program List / Administration / Electronic Signatures / eSignature Query.

Don't forget these invaluable tools as well:



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)