| |
Customer Success Story
Synergy/DE-based solution integrates real-time with SQL Server applications
A division of ITW Ltd., James Briggs is the market leader in the manufacture of specialty chemicals and aerosols. They use Synergy/DE SQL Connection to enable real-time integration with third-party SQL Server applications.
James Briggs’ core manufacturing and accounting systems are part of a SQL Server packaged system that cannot be expanded, changed, or enhanced. (They plan to convert this system to Synergy/DE.) They also have a Synergy/DE-based application that provides functions that the other system does not, such as customer returns tracking, control and tracking of new product sampling/development, and complex formulation costing.
The company needed their Synergy application to extract and manipulate the SQL Server data, so they used Synergy/DE SQL Connection to read the tables within the SQL database. They then stored the data in Synergy DBMS files. This process was initially set to run nightly to keep the two systems in sync.
Some of James Briggs’ users, however, did not want to wait until the overnight data conversion to get current data. So, to keep the data continually up-to-date, James Briggs implemented triggers in the SQL Server database that notify them when the data changes. And they created a Synergy batch routine that runs as a background process and updates the Synergy DBMS files when the SQL Server data changes.
“As a result of this implementation, we are now able to pull up-to-date SQL Server data on the fly,” states Keith Hill, lead Synergy/DE developer at James Briggs.
Integrating with other third-party applications
In addition to enabling the communication between these two disparate systems, James Briggs also uses SQL Connection to enable real-time integration of the SQL data with other third-party applications. For example, James Briggs uses SDSPro to classify their products for health and safety and transport legislation. This involves a process in which they use SQL Connection to read their SQL database and then pass their product recipes to the third-party software using XML.
SDSPro reads the XML data and performs a set of complex calculations to decide which health and safety and risk phrases the product requires. The relevant safety data sheets are then produced automatically and sent to the customers.
When the sales dispatch staff needs to prepare a consignment of products to send to a customer, they enter the consignment number into the Synergy/DE-based application, which uses SQL Connection to pull the dispatch data from the SQL database. It then gets the health and safety data from the SDSpro system and builds up a consignment of different products on different pallets. The end result is that the products are shipped in compliance with the transport rules, and they include the relevant supporting documentation.
“SQL Connection is extremely easy to use and a very reliable piece of software,” concludes Hill.
“We have found that using this product has significantly improved productivity and has allowed us to keep up-to-date with increasingly more complex legislation.” |
|
| |
Strong prototyping
In traditional Synergy Language code, parameters passed to routines (subroutines and functions) are not checked to see if they conform to the way they are defined in the routines. While this allows tremendous flexibility in dynamically determining the parameters passed to a routine, sometimes a more managed approach is called for. This is where strong prototyping is useful. Strong prototyping, which will be available in Synergy/DE version 9, is the result of a combination of tools: namespaces, dblproto, and parameter modifiers.
Namespaces are logical groupings of classes, structures, and routines that can be used to group APIs of common functionality. Namespaces can be imported into another source module to add the prototype information to that compilation. Dblproto is a tool that reads Synergy Language source code and produces prototype files for the classes and routines in the source file. Parameter modifiers are used to place limits on the kinds of data that can be passed to routines.
The name of a routine, its return type, its modifiers and parameters, and their modifiers make up the signature of the routine. Strong prototyping makes sure that the signature of the routine being called matches the call of the routine. We’ll use the following class definition as an example:
namespace testsig
class class2
public method class2
proc
endmethod
endclass
class class1
public method class1
proc
endmethod
public method m1 ,void
in p1 ,i8
out p2 ,d5.2
p3 ,@class2
inout p4 ,d
p5 ,a
endparams
proc
p2 = 1.1
p4 = 4
mreturn
end
endclass
endnamespace
IN, OUT, and INOUT are direction modifiers. IN indicates that data will be passed into the routine but not modified. OUT means that data will be returned and therefore must be writable. INOUT indicates that data will be passed in, modified, and returned and therefore must also be writable. Processing the above code with dblproto results in two files that each describes a class defined in the file. The file for the class named class1 will look like this:
.nolist
.ifndef TESTSIG_CLASS1_DBH
.define TESTSIG_CLASS1_DBH
; Generated by dblproto on 21 DEC 2006 15:37:37
; export directory :C:\dev\dbl\src\cmp_new\
; From sources testsig.dbl
prototype
class class1
public method m1, void
in p1, i8
out p2, d5.2
p3, @testsig.class2
inout p4, d
p5, a
endmethod
endclass
endprototype
.endc
.list
If the following source file is compiled, importing the testsig namespace strongly prototypes method m1 in class2 and therefore reports an error on the second and third calls to the method in the main routine:
import testsig
main
record
f1 ,d4.2
f2 ,@class1
f3 ,@class2
f4 ,d6
f5 ,a10
proc
f2 = new class1()
f3 = new class2()
f2.m1(3, f1, f3, f4, "Hi there")
f2.m1(4, f5, f3, 7, "Hello")
%DBL-E-BSTMTCH, Best match for testsig.class1.m1(I8,ID,@testsig.class2,D,A)void has some argument types or quantity that don't match
f2.m1(4, f1, f3, 7, "Hello")
%DBL-E-OUTPARM, Must be able to write to argument 4, it was declared as OUT or INOUT
end
The first error is generated because the second parameter’s alpha type does not match the type of the method given in the prototype, which is implied decimal. The second error is generated because the fourth parameter is a literal and therefore cannot be written to as required by the INOUT modifier specified in the prototype.
Other modifiers that can be used on parameters in prototypes are as follows:
- BYVAL, to pass the parameter by value
- BYREF, to pass the parameter by descriptor
- CLS, to pass the parameter in a way that is compatible with .NET
- MISMATCH, to allow alphas to be passed in to decimal parameters
- OPTIONAL, to allow the parameter to be skipped
- REQUIRED, to require that the parameter always be passed
Routines can be prototyped to have variable numbers of parameters following a list of zero or more defined parameters by adding the VARARGS modifier to the routine. For example, the following subroutine definition allows varying arguments to be passed after the initial required ones:
subroutine sub1 ,varargs
required type ,i
required count ,i
proc
end
If the SYNDEFNS environment variable is set to “myns”, running dblproto on this file allows importing of the myns namespace, which includes the above subroutine. The following code illustrates how required and variable parameters are handled and what errors can result if the signature embodied in the prototype is not matched in a call:
import myns
main
proc
xcall sub1(3, 2, "abc", "def")
xcall sub1(, 4, 2, 4)
%DBL-E-REQPARM, Missing required parameter 1 in routine sub1
end
The first call matches the prototype, but the second is missing the first parameter, which is marked as required.
Routines defined in the current compilation are also checked to see if calls to them match the signature they were given when they were defined.
As you can see, strong prototyping can help ensure that calls to methods, subroutines, and functions pass the data that is expected. You will now be able to detect many more issues at compile time—issues that previously would not have been discovered until runtime.
Read more about version 9’s strong prototyping in Roger Andrews’ latest blog entry.
top |
|
