developer's guide for broker - baansupport.combaansupport.com/docs/baan/developers guide for...

iBaan OpenWorld 2.2 Service Pack 1

Developer's Guide for Broker

A publication of:

Baan Development B.V. P.O.Box 143 3770 AC Barneveld The Netherlands

Printed in the Netherlands

© Baan Development B.V. 2002. All rights reserved.

The information in this document is subject to change without notice. No part of this document may be reproduced, stored or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Baan Development B.V.

Baan Development B.V. assumes no liability for any damages incurred, directly or indirectly, from any errors, omissions or discrepancies between the software and the information contained in this document.

Document Information

Code: U7543C US Group: User Documentation Edition: C Date: February, 2002

i

Developer's Guide for Broker

1 Product overview 1-1 Introduction 1-1 Overview of features 1-2 Application integration 1-4 Messaging 1-5 Introduction 1-5 Incoming messages 1-6 Outgoing messages 1-7 XML documents 1-7 Additional features 1-7 Periodic processes 1-7 Alerts 1-8

2 Organization of the system 2-1 OpenWorld Broker 2-1 NT service 2-1 Object repository 2-2 Data storage 2-2 OpenWorld Designer 2-2 COM interface 2-3 Configuration utility 2-3 Broker monitor 2-3 Log viewer 2-4 Type importer tool 2-4

3 Repository browser 3-1 Introduction 3-1

4 Working with objects 4-1 To create objects 4-1 Naming rules 4-1 To manipulate existing objects 4-1 Object versions 4-2 To obtain object information 4-2 To change object flags 4-2 To export and import objects 4-3 Object relations 4-4 Special folders 4-5

Table of contents

Table of contents

Developer's Guide for Broker ii

5 Basic concepts 5-1 Object and class 5-1 Properties and operations 5-1 Logical data type 5-1 Value 5-2 Expression 5-2 Variable 5-2 Scripting example 5-3

6 Logical data types 6-1 Structure and purpose 6-1 Creating logical data types 6-3

7 Scripting 7-1 Purpose 7-1

8 Component integration 8-1 The component integration subsystem 8-1 Example cases 8-2 Components 8-5 Logical data types and components 8-6 Integration operations of types and values 8-7 Synchronization 8-9 Time stamp order 8-10 Two-phase commit protocol 8-11 Rollback 8-13 Primitive operations 8-14 Variables and parameters 8-15 Examples of primitive operation implementations 8-15 Mapping objects 8-19 Mapper extensions 8-19 Example using mapper extensions 8-20 To set up the integration 8-20 The process 8-21 Code mapping 8-21 Purpose 8-21 Structure of the mapping table 8-22 GUID 8-22 Operations 8-23 Technical details 8-23 Iterators 8-24 Communication mechanisms 8-24

9 Messages 9-1

Table of contents

Developer's Guide for Brokeriii

Introduction 9-1 Message objects 9-1 To handle incoming messages 9-1 Purpose 9-1 Supported technologies 9-2 Actions 9-2 Procedure 9-3 To send messages to applications 9-3 Facilities for sending e-mail 9-4 To send messages to users 9-4

10 Tools and assistants 10-1 Tool dock 10-1 Expression tool 10-2 Fields tool 10-2 Fonts tool 10-2 Color tool 10-2 Action wizard 10-5 Function of the action wizard 10-5 Macros in e-mails 10-6 Variables 10-6 Type assistant 10-7

11 User management 11-1 User objects 11-1 To log on 11-2 Access rights 11-2 User environment 11-3

12 Language support 12-1 Introduction 12-1 To enter texts in multiple languages 12-1 To set the user language 12-2 Text export 12-2

13 Version control system 13-1 Introduction 13-1 Purpose 13-1 Check out and check in 13-1 External version control systems 13-2 To set up the VCS 13-2 User data 13-2 Object information 13-2 Objects not under version control 13-4

Table of contents

Developer's Guide for Broker iv

To view information about version-controlled objects 13-4 Check out, check in, undo check out 13-5 Locking 13-6 Labels 13-6 To put labels on objects 13-6 To use labels 13-8 Restore old object versions 13-9 Get 13-9 Rollback 13-9 Export and import 13-10 Impact of VCS on export and import 13-10 Export labeled objects 13-10 Discard old object versions 13-11

14 Logging system 14-1 Introduction 14-1 The Log viewer 14-3

15 COM interfaces 15-1 Introduction 15-1 Purpose of the COM interfaces 15-1 Overview example 15-2

16 User interface 16-1 Introduction 16-1 Drop-down menus 16-1 Windows and dialog boxes 16-1 Forms 16-2 Queries 16-2 The main window 16-3 Messages 16-3

17 User-definable objects 17-1 18 Index 1

Developer's Guide for Brokerv

This document describes the capabilities and use of Baan OpenWorld Broker and Designer.

This document can be used in the following ways:

Developers can use this document if they integrate applications using the Baan OpenWorld Broker.

Administrators and developers can also use this document if they want to configure and customize the Broker, for example, by adding menus and commands.

System administrators can use this document when they manage user accounts, the logging system, database connections, and so on.

Chapters 1 through 7 introduce the Broker and the main components of the Broker.

Chapters 8 and 9 provide a detailed description of the component-integration system and the messaging system. For further details on integration see the Baan OpenWorld 2.2 Integration Guide (U7664A US)

Chapter 10 describes a number of system utilities, such as the tool dock and the type assistant.

Chapters 11 through 16 describe the other features that you can use to build applications in the Broker.

Chapter 17 gives an overview of the objects you can define. These objects are described in detail in Baan OpenWorld Broker Reference Guide (U7461B US)

For details about the scripting language, refer to the Scripting Language Reference (U7278E US).

For details about the COM Interfaces, see Baan OpenWorld Broker COM Interfaces.

About this document

About this document

Developer's Guide for Broker vi

Definitions, acronyms, and abbreviations Term Definition AMI Application Messaging Interface.

AMI is the OAG's standard Application Messaging Interface, endorsed by IBM. AMI uses a set of policies which hold details of how messages are to be handled, for example, priority, confirmation of delivery, timed expiry.

Asynchronous communication

Data-communication system in which the application that sends data does not wait for the completion of the communication. Typical technologies for asynchronous communication are e-mail, message queue software, and batchwise exchange of data files.

Baan OpenWorld Baan OpenWorld is a suite of products that provides the complete integration framework to connect Baan applications with one another as well as with any third party or homegrown application.

BizTalk framework

A set of guidelines for implementing an XML schema and a set of XML tags used in messages sent between applications. (See www.biztalk.org).

BOI Business Object Interface. DLL Dynamic-Link Library; a file containing software functions which are ready

for use by any application that links to the DLL. DNS Domain Name System; Domain Name Server. DTD Document Type Definition; A DTD defines the structure of a certain type of

XML document. GUID The Globally Unique Identifier of an object.

A GUID is displayed in the form "{19091955-BB74-11D2-95E2-00805FA3A240}.”

HTML Hypertext Markup Language. MAPI Mail Application Programming Interface. MDI Multiple-document interface; a user interface in an application that enables

the user to have more than one document open at the same time. MSMQ Microsoft Message Queue Server. ODBC Open Database Connectivity; a programming interface that enables

applications to access data in database management systems that use SQL as a data access standard.

SMTP Simple Mail Transfer Protocol. SQL Structured Query Language; a data access standard for databases. SSL Secure Sockets Layer; a security protocol used for securing

communications on the web. Synchronous communication

Data-communication system in which a transaction in one application component involves immediate data transfer to the other application component. The communication is so fast, that the component can wait for completion of the communication before proceeding.

About this document

Developer's Guide for Brokervii

Typical technologies for synchronous communication are COM, DCOM, and CORBA.

UNC Universal Naming Convention; the system for indicating names of servers and computers, such as "\\Servername\Sharename."

VCS Version Control System. XML eXtensible Markup Language. XML schema A language to define the structure of XML documents that contain data.

For example, you can define an XML schema for documents that contain purchase orders. XML schema is a W3C recommendation, see http://www.w3.org/TR/xmlschema-0/

About this document

Developer's Guide for Broker viii

Developer's Guide for Broker1-1

Introduction The Baan OpenWorld Broker is a system you can use to integrate business applications using both synchronous and asynchronous communications methods. You can use the Baan OpenWorld Designer to configure and customize the integrations.

The Broker applications consist of collections of objects, stored in a repository. By building logical data types, you can define a data structure which is independent from any physical representation. If you model your business domain by using these logical data types, you can link the data model to any application. You can use this link to send data between applications, but you can also enable multiple applications to participate in operations on your data. In this way, you can combine component applications to form a well-integrated, component-based system.

The component applications do not need to be modified, provided that they support reasonable interfaces to the outside world.

The Broker's component integration subsystem is described in detail in Chapter 8, “Component integration,” and in the Integration Guide.

The Designer has a native scripting language with a syntax based on C++. You can also use IActiveScripting compatible languages, such as VBScript. For more information, see Chapter 7, “Scripting”.

1 Product overview

Product overview

Developer's Guide for Broker 1-2

Overview of features The following tables present an overview of features of the Broker.

Supported technologies to connect applications Feature Description Where

documented COM Automation The Broker can access Microsoft COM

Automation objects from within its scripting language. This feature offers a powerful method to integrate with other applications that provide access through a COM client.

Chapter 8

BOIs The Broker connects with BaanERP through Business Object Interfaces (BOIs).

Chapter 8

Thin client The Broker's COM interfaces can be used as a thin client for work with an application, data entry and retrieval, and so on. You can run the thin client in any container that works with COM components, for example Internet Explorer, Visual Basic, and so on.

Chapter 15

DLLs The Broker can access DLLs on the workstation of the user.

The DLL proxy section in the Reference Guide

ODBC databases The Broker can access ODBC-compliant databases either by using a mapping of internal table types with database tables, or by using free-style SQL statements.

The Database connector and File sections in the Reference Guide

File access The Broker can write to and read from text files.

The File section in the Reference Guide

Product overview


Supported communication technologies Feature Description Where

documented E-mail The Broker supports the SMTP, POP3, and

MAPI protocols for e-mail systems. The Broker can send e-mail messages and process incoming e-mail messages. Incoming e-mail messages can be converted to internal data types.

Chapter 9

Message queues The Broker can receive messages from Microsoft's MSMQ and AMI-compliant software, such as IBM's MQSeries message queue software.

Chapter 9

XML, Biztalk The Broker can process messages in XML and Biztalk framework format.

Chapter 9

Internet protocols The Broker supports the HTTP and FTP Internet protocols and handles documents in HTML format.

Chapter 12 in the Reference Guide

Additional functional features Feature Description Where

documented User interface Building blocks to create user interfaces,

such as forms, menus, and message boxes. Chapter 16

Periodic processes

Automatic execution of recurring activities, such as system administration tasks.


Alerts Continuous monitoring of critical performance indicators and alerting a user if the indicator exceeds certain limits.


Messages to users

A system to send messages to the mailboxes of users of the Broker.

Chapter 9

Workflow A system to control the flow of documents to users for further handling.

The Workflow section in the Reference Guide

Product overview


Technical features Feature Description Where

documented COM interfaces The Broker exposes its services to COM

clients by means of COM interfaces. A COM interface enables external programs access to the objects in the object repository.

Chapter 15

Scripting language

A powerful scripting language allows you to build and customize integration applications.

Chapter 7

IActiveScripting Integrations can be programmed using IActiveScripting-compliant scripting languages, for example, VBScript.

Chapter 7

Version control system (VCS)

A system to control and store versions of objects.

Chapter 13

Logging system A system to log errors and other events. Chapter 14 Export and import Exporting and importing of objects for

backup or distribution of objects to other servers.


Language and translation support

Storing texts in multiple languages and displaying the user interface in the user's language. Multibyte and Unicode encoding of messages.

Chapter 12

Application integration The Baan OpenWorld Broker is a system you can use to integrate business applications using both synchronous and asynchronous communications methods.

At the core of an integration solution are the logical data types. By creating logical data types (also simply named “Types”), you define a data structure with rows and tables that models your business domain. The business applications you integrate are represented by component objects in Broker. Multiple components can participate in a type. For example, a Product Data Management (PDM) system contains a product’s bill of material, and a Warehouse Management system (WMS) contains the storage locations of the same product. Information that is common in both applications, for example, product description, can be synchronized through Broker. When you execute a synchronize operation on a type, all data about the product is uploaded to Broker, and subsequently stored in all participating components.

Product overview


You can connect to the participating components in several ways:

You can access the application through its COM client.

You can use SQL statements to access a database through an ODBC connection, by using database connectors or file objects.

You can use BOIs to access BaanERP.

Each of these ways provide synchronous communication with the participating components. These connections are facilitated by mapper extension objects that execute the Load and Store operations, and so on, for a particular component.

You can define complex transformations of data in mapping objects.

Broker maintains a central code mapping table to map between the primary keys of records in multiple applications. For example, you can map a CustomerId field in one application to a ClientNumber field in another application.

You can set up batch processing of data by defining iterators. An iterator loads a large amount of data at one time, processes the data, and stores the data in the participating components. You can control the batch processing by defining task objects, profile objects, and periodic processes.

You can also connect to component applications by sending and receiving messages. That is a form of asynchronous communication, that is described in the next section. Broker has special facilities for processing XML documents.

Messaging Introduction The messaging subsystem gives the system the ability to act as a publish and subscribe tool.

Messaging, or publish and subscribe, refers to a software architecture in which multiple applications, in many cases running on several server computers, integrate by informing each other of significant events.

For instance, a customer management application can often publish an event every time a customer’s address changes. Other applications, such as BaanERP, can subscribe to this event and update their databases, for instance, the element master, automatically.

SYNCHRONOUS COMMUNICATION

BATCH PROCESSING

ASYNCHRONOUS COMMUNICATION

Product overview


Messaging combines the security and integrity of online transaction services with the front-end responsiveness of queued batch processing. Posting an asynchronous message is a quick operation, while delivery and eventual updating of the central database is guaranteed. Posting can be seen as a near-real-time operation. For instance, a restaurant chain can have a number of restaurants that use front-end sales systems, which post sales information back to headquarters by using messaging. At headquarters, near-real-time sales data is continuously available for analysis. Meanwhile, individual restaurant systems operate at full speed, even if communications links go down.

Near-real-time posting is only appropriate for write-only operations and data collection at the back end. Read-and-update operations, such as when you subtract sold goods from inventory after you check for availability, must have true online transaction processing.

Incoming messages Incoming messages are processed by using three types of objects:

Message source Message queue Message handler

The messaging system uses the following procedure:

1 A periodic process or another script runs the poll operation of a particular message source object.

2 As a result of the poll operation, the message source checks if any message is present. You can configure the message source for several transport methods, for example, email, or Microsoft Message Queue.

3 The message source translates the message into a value of a logical data type and puts this value into a Message object. Typically, the logical data type is a row type (a record of data) or a simple text string (the Broker primitive type String).

4 The message source moves the message onto a message queue object.

5 When the poll operation of a message handler is invoked, it looks for messages in the message queue.

6 The message handler picks up the messages in the message queue, and executes the actions you defined for the message handler.

You can define a periodic process to run the poll operation, for example, once every 10 seconds.

NOTE

Product overview


Outgoing messages You can send outgoing messages by using a message sink object. The message sink takes a Broker value, for example a row of data or a text string. The message sink translates the value, and sends the message by using a message transport. You can configure the message sink for several transport methods, for example, email, or Microsoft Message Queue.

XML documents Broker has special functions to translate a value of a Broker type to an XML document or the other way round. XML document are specially suitable to send data between applications.

Additional features Periodic processes A periodic process is an object that controls a process or task that runs repeatedly at predefined intervals or according to a more elaborate recurrence scheme. Periodic processes can perform a variety of tasks, for example:

Collect a history of certain financial indicators for a company. Start a daily data synchronization process. Initiate system administration tasks, such as making backups, or performing

regular checks. Poll message sources and message queues.

For more information, refer to “Periodic process” in Chapter 1 in the Reference Guide.

Product overview


Alerts An alert is a warning that a variable has a value that is either too high or too low, or increases or decreases at too high a rate. You can use this feature to monitor critical business performance indicators.

Alerts are generated by a special type of periodic process called alerters. An alerter regularly checks the value of a specified timed variable or expression. If the value exceeds certain bounds or changes very fast, the alerter automatically responds by executing a user-defined action. For example, the alerter can send an e-mail notification, a Broker message, initiate a workflow, or run a script.

In its simplest form, an alerter monitors the value of a timed variable. You can also create a program script to monitor the result of a complex formula. For details, refer to “Alerters” in Chapter 1 in the Reference Guide.


OpenWorld Broker The Baan OpenWorld Broker is the server that serves various client programs. The most important client is Baan OpenWorld Designer. The clients connects to the Broker through a TCP/IP protocol.

The server runs under the Windows NT operating system.

The Broker server consists of a kernel and an object repository. The kernel executes the processes of the server and an object repository stores all objects.

The main functions of the server are:

To store objects in the central object repository. To serve objects to clients that edit or use the objects. To execute periodic processes and alerters. To run the workflow engine.

NT service The Broker runs as a Windows NT service. The Broker does not have a user interface. The Broker service is configured to start automatically when the server system is started. You can also start or stop the Broker service manually.

To start or stop the Broker service:

1 On the Windows task bar, click the Start button, point to Settings, and click Control Panel.

2 In the Control Panel, double-click Services.

3 Click the Baan OpenWorld Broker service.

4 Click Start or Stop.

2 Organization of the system

Organization of the system


Object repository The object repository is a simple, proprietary database, optimized for Broker objects. The object repository is stored in a single file. You can specify the object repository file in the configuration utility.

Objects are serialized and stored as a stream of bytes. Broker uses several caches to achieve a high performance level. Objects can be stored in compressed form.

The integrity of the object repository is ensured by a transaction system. The object repository never implements an incomplete transaction. If the application terminates abnormally, the system uses a roll-back mechanism to restore the object repository to its last secure status.

If the bis.cor (repository) and the bis.rlo (rollback) exist, files have to be kept together for repository integration.

Data storage Usually, you do not store your data internally in the Broker. The Broker has special features to connect to external databases, which you use for permanent data storage.

You can also store data in global-variable objects, which are held in the object repository.

OpenWorld Designer The Baan OpenWorld Designer runs on the user’s workstation. The Designer runs on Windows 98 and Windows NT.

The client can be used by developers of applications and by the end users that run these applications. You can use the Designer to:

Send commands to the server. Display objects. Open a repository browser to access the objects in the object repository. Create and edit objects.

To open a repository browser and to edit objects, you must have superuser access.

NOTE



COM interface The Broker provides COM interfaces that enable access to the object repository from any container that works with COM components, for example Internet Explorer, Visual Basic, and so on.

To access the Broker COM interfaces, users must register the bsrvitf.dll file on their workstation. If you install the Designer, the install program registers bsrvitf.dll for you.

Configuration utility A special configuration utility enables you to configure the server and client programs. The configuration utility is a plug-in for Microsoft Management Console (MMC). If you install the Broker, the installation program installs and registers a COM control that you can open in MMC.

To configure the Broker or the Designer, take the following steps:

1 Start the Baan OpenWorld Broker Configure program.

2 In Microsoft Management Console (MMC), open the folders in the Console Root window.

3 Right-click the Broker or the Designer icon.

4 In the shortcut menu, click Properties.

5 Specify the settings as you like.

In general, the changes you make in the configuration utility will take effect after you restart the Broker, the Designer, or both.

Broker monitor The Baan OpenWorld Broker Monitor enables you to see which clients are currently connected to the server.

The Broker Monitor also displays debug notifications from the server for all clients. For example, if a script uses the System.debug operation or the printf statements, Broker routes these messages to all active Server Monitors. The printf statement still displays a message box if the script is evaluated on the client, for example, in buttons on forms.

You can configure the Server Monitor to accept these messages or not. You can also configure to how many messages the Server Monitor must buffer.



Log viewer You can view the results of a job or transaction by using the log viewer. You can use the log viewer also to start synchronization jobs and other activities of the Broker. These activities are defined by using profile objects.

Type importer tool The type importer tool is a separate product that allows you to define logical data types in text-based formats and import these into the repository.


Introduction Both system objects and application objects are stored in a single central object repository. If you have superuser access, you can open the repository browser to manage the objects in the object repository. To open the repository browser, on the File menu, click Repository browser. The following figure (see Figure 1) shows a screen shot of the repository browser.

Figure 1 The repository browser

3 Repository browser

Repository browser



To create objects To create objects, you can either use the buttons in the repository browser, or click the New button on the Objects menu. If you create a new object of a particular type, the editor for that type of object is started, for example, the form editor.

Naming rules Object names must be no longer than 255 characters, must consist only of alphanumerical characters plus the underscore (_) character, and must not start with a number. Object names are case-sensitive.

For detailed instructions on how to create objects, see Chapter 1 in the Reference Guide and the online Help.

To manipulate existing objects In the repository browser, you can modify, move, copy, rename, and delete existing objects. For most of these operations, you must first select an object by clicking the object in the repository browser. You can then click the corresponding command on the File menu or on the Edit menu.

You can also:

Modify an object by double-clicking the object.

Move an object by dragging the object to another folder. To create new folders, you must click the New Folder button on the toolbar.

Copy or move an object by means of the Cut, Copy, and Paste commands on the Edit menu.

Rename an object by double-clicking the name of the object.

Open a shortcut menu with additional functions by right-clicking an object.

4 Working with objects

Working with objects


Object versions If an object is maintained under the version control system (VCS), you must check the object out before you can make any changes. Earlier versions of the object are automatically archived for future reference.

You cannot modify the VCS status of objects unless you have access rights for the VCS.

For more information, see Chapter 13, “Version control system.”

To obtain object information You can obtain useful information about the status of an object in an object's dialog box. To open an object’s Information dialog box, take the following steps:

1 Select the object in the repository browser.

2 On the Objects menu, click Info.

The dialog box shows information about, for example, the object’s creation date and the user that created the object, the locking status, and so on.

To change object flags To change the object flags, you must first open the object’s Information dialog box as described before in the Section “To obtain object information”.

The following table lists the object flags that you can set on the Flags tab of an object’s dialog box.

Flags Flag Description Compressed If you enable this option, the object is stored in compressed form.

Compressed objects require additional processor time for decompression, but they occupy less space in caches and are transmitted more quickly over a network.

Protected You cannot modify protected objects. The protected status is used for objects that are required for the system to work. You can only enable turn the protected flag on or off if you use the Archive.setFlags operation in the scripting language.

Enable VCS Specifies that the object is under version control. For more information, see Chapter 13, “Version control system.”

Logging flags

The logging flags specify the events for which the Broker generates a log entry. For more information, see Chapter 14, “Logging system.”



To modify the flag status of multiple objects from several folders in a single action, you can use the Change Object Storage Flags dialog box. This dialog box is started by means of the setFlags operation of the Archive object.

To open the Change Object Storage Flags dialog box, take the following steps:

1 Click Open Tool Dock on the File menu. You can also find the Open Tool Dock command on the Objects menu in the repository browser.

2 Enter the following expression in the Tool Dock’s Expression tab: Archive . setFlags

3 Click Evaluate.

To make operations such as this more readily available to you, place these operations in a menu. For more information, refer to “Menu” in Chapter 1 in the Reference Guide.

To use the Change object storage flags dialog box:

1 In the Change object storage flags dialog box, add or remove objects from the Objects to change list until you are satisfied with the resulting selection.

2 Indicate which flags you want to turn on or off by selecting one or more of the following check boxes: −−−− Set Compressed Flag. −−−− Set Protected Flag. −−−− Set Version Control System Flag. −−−− Set Logging Flags.

3 Select or clear the Compressed check box to indicate whether the flag must be turned on or off.

4 Set the remaining check boxes and option buttons according to your requirements.

5 Click OK.

To export and import objects You can export objects from the object repository to a file. You can keep this file as a backup of your objects, or you can import the objects on another server. For more information, see Chapter 8 in the Reference Guide, “Exporting and importing objects.”

NOTE



Object relations The Broker stores relations between repository objects in a separate database table. The most common relation type is the DEPENDS_ON relation. For example:

You define a message source object “MSource” which uses a message queue object “MQueue”. In this case, the MSource object depends on the MQueue object.

The repository server automatically updates object relations as objects are modified and saved in the repository.

To view an object’s dependencies:

1 Select the object in the repository browser.

2 On the Objects menu, click Info.

3 Click the Dependencies or Dependents tab.

You can use object dependencies when you export or import collections of objects to or from a file.

You can also use object relations in the scripting language.

For more information, see OpenWorld Broker Reference Guide (U7461B US)



Special folders The following table lists a number of object repository folders that have a special function.

Special folders Folder Function \apps Stores a number of predefined applications, such as the mailbox

viewer and the event-log viewer. \predef\CODA Stores objects used to communicate with CODA-Financials servers. \predef\system Stores built-in objects, for example the objects that represent

predefined types. You cannot change these objects. \sys Contains subfolders that store system objects, such as database

connectors for the code map and logging system, user mailboxes, and so on.

\sys\alertvalues Used by alerters to store the results of the evaluation of a checked variable or expression.

\sys\biztalk Stores logical data types used by the translator of Biztalk messages.\sys\databases\workflow Workflow history logging \sys\databases\cis Component integration subsystem: the code map table and

component instance information \sys\databases\relations Object relations \sys\documents Workflow documents \sys\events\notifications Mail notifications \sys\mailboxes Stores the user mailboxes. \sys\operations User defined operations on system objects \sys\preferences User preferences \sys\processes Stores active periodic processes and alerters. \sys\system\abrowse Stores the menu for the repository browser. \sys\system\defaults Stores the Broker default menu. \sys\system\workflow System objects and settings for the workflow subsystem \sys\vcs Used by the version control system to store internal information

about object versions. \sys\xml Stores logical data types used by the translator of XML documents. \users Stores users and user groups. \vars Stores timed variables that can be monitored by alerters.


In this chapter, the basic concepts of the Broker are explained.

Object and class

Properties and operations The Baan OpenWorld Broker has an object-oriented structure. In other words, the Broker consists primarily of objects. Each object has certain properties and operations that the user can access through the scripting language. For example, the system object Abrowse represents the repository browser. This object has an operation smallIconView(), which switches the view of the repository browser to small icons.

In addition to the predefined objects of the system, such as Abrowse, System, and CodeMap, you can define your own objects. Each object belongs to a certain class. An object's class determines the types of properties and operations the object has. For example, all objects of the User class have properties such as Name, Password, and E-mail address, and operations such as sendMessage.

Logical data type Logical data types, which are also sometimes called types, describe the nature and structure of data. This logical data description is independent of the physical form of the data being processed. Some simple types are predefined, for example, String, Number, and Time. You can use these simple types to build composite logical data types, which represent objects in your application domain, such as a customer or a sales order.

The most common kinds of logical data types are row types and table types:

A row type consists of a number of fields, for example, the Name, Address, and Phone fields.

A table type is a collection of values of a row type on which you can run operations, for example, you can insert a new row, delete a row, sort, and so on.

5 Basic concepts

Basic concepts


Value Each unique instance of logical data types is called a value. The numbers 42096 and -0.107 are values of the logical data type Number. The text “honeybee” is a value of the logical data type String. For example, suppose that you have defined a CustomerRow row type to store data about customers. As a result, an instance of this logical data type is a value that represents one particular customer.

Expression An expression is a sort of calculation procedure. If an expression is evaluated (calculated), the expression produces a value. Example expressions:

12+3. System.queryTime.

The expression 12+3 produces 15, which is a value of type Number. The expression System.queryTime produces the system time, which is a value of type time.

Variable A variable is capable of holding a value of a certain logical data type. You can use these variables in an expression.

In a script, you can define variables to store values while the script runs. If you want a variable to hold a value during a longer period, you can define one of the following types of objects in the object repository:

Global variable. Timed variable. File objects.

You can also use these objects as variables in an expression. For a detailed description, see the relevant sections in Chapter 1 in the Reference Guide.

If you assign a new value to a variable, the type of the value must match the type of the variable. You can invoke the operations of the logical data type of the variable. For examples of variables, refer to the following section.

Basic concepts


Scripting example This section shows what variables and types look like in the scripting language. However, the syntax and semantics of this example script are not explained in detail.

The example script contains:

The logical data types String and CustomerType. The variables strName and cust. The operations new, uppercase, and store.

This scripting example first defines two variables, and then assigns values to these variables; the values are the results of expressions. You can also see how operations are invoked.

{

String strName;

CustomerType cust;

strName = "Theodorus";

cust = CustomerType . new ();

cust.name = strName . uppercase();

cust . store ();

}

Basic concepts



Structure and purpose Logical data types describe the nature and structure of data. This logical data description is independent of the physical form of the data being processed.

Logical data types are often simply called types.

The Broker has a number of built-in logical data types, such as String, Number, Time, and Sound. These built-in types are described in Chapter 2 in the Reference Guide, “Built-in primitive types.” You can combine these primitive types to create composite logical data types. To define operations for logical data types, you can use the scripting language.

There are four different variants of user-defined logical data types, as described in the following table.

Logical data types Data type Description Row A collection of data fields, each of which can have a different

logical data type. You can use a row type to define the structure of records. For example, Employee number (Number), Name (String), Date of birth (Time), Department (String).

Table A collection of elements of the same type. The number of elements in a table can grow or shrink as required. For example, you can store a list of customers in a table.

Array A collection of elements of the same type. Arrays have a fixed number of elements. For example, you can use an array of strings with 12 elements to store the names of the months.

Enumeration An enumeration type is a logical data type describing the status of an object or event. Each possible status is represented by a name. For example, an enumeration type StudentLevel can consist of the names: Novice, Intermediate, or Advanced.

Applications defined in the Baan OpenWorld Broker are usually built around a number of table types and row types.

A logical data type only describes the nature and structure of data. The logical data type cannot store any data in itself. The Broker provides several ways to store the data.

6 Logical data types

NOTE

NOTE

Logical data types


Global variable

You can use a global variable to store tables directly in the Broker repository.

File object

You can use a file object to link a table directly to an external source, such as an ODBC-compliant database or a comma-delimited ASCII file. In the scripting language, you can use the file object as a variable of the table type. For more information, see “File” in Chapter 1 in the Reference Guide.

Multicomponent applications

In more complex situations, the table data is stored in multiple external applications. Each external application, also called a component, can participate in a logical data type by means of the component integration subsystem.

For example, suppose you are a supplier of chemicals and you have a database application with safety information on hazardous materials and a business application with sales data. You can create a logical data type for chemicals in which both applications take part.

In the scripting language, you can declare a variable of a logical data type, and use the load operation to populate the variable with data from the participating components. For more information, see Chapter 8, “Component integration.”

Logical data types


Creating logical data types The following figure (see Figure 2) shows the type editor that you can use to create logical data types. This example shows the CustomerRow row type that has fields such as the CustomerId and CompanyName fields. You can also see how the components, BFO and CF, are placed in the definition of the type. The type definition exactly specifies how values of this type interact with the components BFO and CF.

For detailed instructions for the creation of logical data types, refer to “Logical data type” in Chapter 1 in the Reference Guide or the online Help.

Figure 2 The type editor

Logical data types



Purpose The Baan OpenWorld Broker has a powerful scripting language. You can use the scripting language to create scripts and expressions.

You can use scripts and expressions to define:

Actions that must be performed if the user clicks a button or a menu command.

The response of the system to other events that can occur, for example, a message is received or an alerter variable exceeds a critical limit.

Conditions. A condition is something that can be true or false, for example, the statement “The current user has superuser access” is a condition.

Operations on data.

Scripts and expressions

Scripts and expressions are similar items. Both define a sort of calculation procedure. The difference between a script and an expression is:

A script is a list of statements between braces: { and }. Each statement ends with a semicolon (;). If the system executes a script, the script can return values with the help of the return command.

An expression is something that produces a value, for example, the expression 1+2+3+4 produces the result 10.

Types of scripting

native scripting IActiveScripting

For more information, see the Baan OpenWorld Broker Reference Guide (U7461B US) and the Scripting Language Reference (U7278E US).

7 Scripting

Scripting



The component integration subsystem The component integration subsystem enables you to develop integrations between applications. In this way, you can connect independent applications as components of a comprehensive information system. Also see the Baan OpenWorld 2.2 Integration Guide (U7664A US).

The following table lists the characteristics of the component integration subsystem:

Characteristics of the component integration subsystem Aspect Description Logical data modeling

Integrations are built around common logical business objects of the enterprise, independent of the components’ physical data definitions or low-level communication methods. The component integration subsystem models the state and behavior of common objects, not just the movement of data from one component to another.

Communication technology

Many means of communications are supported, both synchronous and asynchronous. For example, APIs, BOIs, direct database updates, COM-based object interfaces, and XML messages.

Loose coupling The components being integrated do not need to know about each other. The complete overview is stored in the Broker, which enables you to easily add, modify, or replace components.

Nonintrusive integration

You do not need to change the source codes of the applications that you integrate. The components only must support some reasonable interfaces to the outside world.

Vendor independence

The component integration subsystem works with users’ in-house or third-party components in exactly the same way as Baan’s own components.

8 Component integration

Component integration


Example cases The following case descriptions provide a clear picture of the capabilities of the component integration subsystem. The scenarios described in this section are:

Data synchronization. Synchronization in a batch process. Online update. Query. Remote entry of documents. Submission of reports by e-mail. Event notification by e-mail.

These examples are not explained in detail here, however, later sections explain how you can use this functionality.

Data synchronization

A component notifies the Baan OpenWorld Broker that data has changed, for instance a customer’s address. The Broker then updates the components to synchronize the other components’ information.

The following steps describe the process to synchronize the components:

1 A component sends out a message to inform the Broker that a piece of data has changed. The component can send a message through a message queue such as MSMQ or MQSeries, by e-mail, or through another way.

2 The Broker messaging system picks up the message through a message source object, translates the message, and writes the message to an internal message queue.

3 A message handler object picks up the message and decodes the component ID and local code. The message handler deducts the logical data type involved from the contents of the message. For example, the logical data type can be Customer.

4 The message handler calls the synchronize operation of the logical data type.

5 The Broker first loads the object data from all participating components, and then stores the compound object back into the participating components. In this way, every component receives the latest version of all data for this object.



Synchronization in a batch process

An ERP application contains a master item master file with codes and descriptions for all items. Every night, the changes in the item file must be sent to a warehouse management system that manages the storage locations of these items. This can be controlled by a periodic process in the Broker. An iterator object is used for efficient synchronization.

The following steps make up the process to send changes to the warehouse management system:

1 The periodic process calls the synchronize operation of an iterator.

2 The iterator accesses the ERP application through a COM interface.

3 The iterator retrieves a table of all new and modified records in the item master file. This table also lists the items deleted from the ERP application.

4 The Broker iterates through the table of modified records. For each record, an instance of the Item logical data type is populated with up-to-date information, and stored back into all participating components. If necessary, items are deleted from all participating components. The data is not updated in the originating component (the ERP application), because that component is considered to be up-to-date. This implies that only the warehouse management system is updated.

Online update

In this case, a client wants to read, update, then resave an existing object instance. A typical client for this scenario would be an in-house application to maintain customer information.

The following steps describe the process to make online updates:

1 The client application accesses the Broker through the COM object, which is provided as part of the Broker.

2 The load operation of the logical data type runs to fetch the object from all participating components.

3 The client modifies the instance data, using the Broker's COM interfaces.

4 The client calls the object’s store operation to store the object in all participating components.

Rollback

If the Store operation fails in any of the components, you can use a rollback function to undo the entire update operation.



Query

A user wants to read an existing object instance for query purposes. The user uses a client application that accesses the Broker, for example, a self-service Web page.

The following steps make up the process to read an existing object instance for query purposes:

1 A script in a Web page accesses the Broker through the COM object, which is provided as part of the Broker.

2 The load operation of the logical data type is run to fetch the object. A component ID and code are passed to the operation. The object data is obtained from all participating components.

3 The client displays the data.

Remote entry of documents

An accounting document is entered in a Web page or spreadsheet and sent to the Broker for processing.

The following steps describe the process to enter the accounting document, and send the document to be processed:

1 A script in the Web page or a spreadsheet macro accesses the Broker through the COM object which is provided as part of the Broker.

2 A fresh instance of an AccountingDocument logical data type is created.

3 The instance is populated with data from the client.

4 A post operation is applied to the AccountingDocument object. The COM client sends the populated value to the Broker remote object server, which calls the post operation in the various components.

5 The result of the posting is returned to the client.

Submission of reports by e-mail

Expense reports can be submitted using e-mail messages, which are queued and processed by Baan OpenWorld Broker.

This scenario is similar to the online case, except that the population of the object instance derives from an arriving message, not from the Broker's COM client.



The following steps describe the process to submit reports by e-mail:

1 A user sends an asynchronous message to the Broker, for example through e-mail or MSMQ.

2 The message is picked up by a Broker message source object, and is then translated and put into a message queue in the repository.

3 A message handler scans the queue. The message is retrieved and processed. As a part of this processing, a fresh instance of an ExpenseReport logical data type is created and populated with data.

4 A post-operation is applied on the ExpenseReport object. The Broker calls the post operation in the various components.

5 Optionally, a result message is sent back to the client.

Event notification by e-mail

A message is sent to the Broker notifying that, for example, a customer has been closed for business.

This scenario is similar to the offline operation invocation. The logical data type that is used to process the data can represent an event, for example, CustomerClosed, or one of the business objects, for example, Customer.

After the incoming message is processed, a fresh instance of this logical data type is created and populated with data. A notification operation, which can be any of the user-defined operations on the object, is applied. Multiple components can participate in this operation to implement their response to the event.

Components Before you can define the relationships between the logical data types and the external applications, you must define the component objects. A component is an object in the repository that describes an external application, for example, BaanFrontOffice or CODA-Financials.

If you want to interact directly with a component, you will usually need a logon script for the component. In this logon script, you can store relevant information about the connection in a Session variable. The Session variable is passed to any component-specific operations, such as Load and GetTimestamp. For more information and examples, see “Component” in Chapter 1 in the Reference Guide.



Session

The connection with a component, the period between log on and log off, is called a session. A component can have multiple sessions running simultaneously.

Logical data types and components Logical data types describe the nature and structure of data independent of the physical form of the data. To do any actual processing, an instance of this logical data type must be created and stored somewhere. In simple situations, a logical data type can be stored in a single database table or in a text file. In more complex situations, the data is stored in multiple external applications, called components. These components can participate in the logical data type. In this case, you must create scripts to define the implementations for operations such as:

To load a logical data type instance into the Broker. To store the instance back in the external applications. To permanently delete the instance.

You must create these scripts for each component that participates in the logical data type.

This works as follows. A logical data type has a number of primitive operations, such as Construct, Load, Store, and StoreNew. For each participating component, you can provide scripts that implement these primitive operations, as illustrated in the following example:

A Finance application and a Sales application participate in the Customers logical data type. The Customers type contains information about the total amount owed by the customer and the current credit limit. In the Customers logical data type, you create a Store script for the Finance application that sends relevant data, for example, Amount owed, to the Finance application. Another Store script sends relevant data, for example, Current credit limit, to the Sales application.

You cannot invoke these component-specific operations directly. In the scripting language, you can call higher-level operations on logical data types, for example, synchronize. These operations activate the component integration subsystem, which invokes the appropriate primitive operations for each component.

In simple cases, you can implement the primitive operations by defining mapper extension objects. This is described in the Mapper extension section, later in this chapter.

NOTE

MAPPER EXTENSIONS



Type-specific operations

Components can also participate in logical data type's high-level, user-defined operations, such as Post, Approve, Query, and so on. You must define the implementation of each component’s participation in these operations.

Integration operations of types and values The component integration subsystem has a number of operations on logical data types and values that you can invoke to achieve some integration function. These operations can be initiated from within the Broker, for example:

A synchronization process that is activated by a periodic process. A synchronization process that is started through a menu command in a

Broker client.

The user can also initiate these operations through an external application that communicates with the Broker by means of the Broker's COM interfaces or by means of a messaging system. For more information, see Chapter 15, “COM interfaces,” and Chapter 9, “Messages.”



The following table lists the available operations for data integration on logical data types and values.

Integration operations Class Operation Description Type load Loads a particular object instance, identified by code, from

all participating components. This operation uses the Construct, GetTimestamp, and Load primitive operations.

Type synchronize The user can call this operation to notify the Broker that an object was inserted or modified in a component. The Broker first loads data from all components, and then stores the resulting compound object in all participating components.

Type delete Removes an object instance from all participating components.

Type map Looks up a component-specific code (primary key) of an object in the code mapping table.

Row new Returns a freshly created, empty instance of the logical data type.

Row store Updates the object in all participating components, by invoking the Store primitive for each component.

Row storeNew Inserts a new object in all participating components by invoking the StoreNew primitive for each component.

queryGUID Returns the Globally Unique Identifier (GUID) associated with the object instance.

In the scripting language, these operations are defined for the Type and Row classes. For details about these operations, refer to the Scripting Language Reference (U7278E US).



You can use the operations of the Type class on logical data types. You can also use the operations of the Row class on variables of row types. For example:

{

// Create a variable to store instances of CustomerType

\types\CustomerType cust;

// (The load operation is an operation on a type).

cust = \types\CustomerType . load ("BAANERP", "012");

// Change the address

cust . Address = "100 Seaview Drive";

// Store the updated record in all

// participating components

// (The store operation is an operation on a row).

cust . store ();

}

Synchronization The synchronization operation is used if an object is inserted or modified in one of the components. This component is called the originating component.

In general, the process to perform a synchronization operation consists of the following steps:

1 Constructs an empty instance of the logical data type.

2 Optionally retrieves a time stamp for the instance from each component. Time stamps are explained later in this chapter.

3 Loads any existing data from the other components into this instance.

4 Loads the new data from the originating component.

5 Checks the code mapping table to see if the object already exists.

6 Updates the resulting object into the other components by using the Store primitive operation. If the object is new, the operation uses the StoreNew primitive operation to insert the object into the other components.

7 Updates the code mapping table if the object was new.



Flags

Usually, the Broker assumes that the originating component already contains an up-to-date version of the object. The Broker will not store the object in the originating component, unless you specify the SYNC_STORE_ALL flag.

If you are certain that the object is new, you can specify the SYNC_ALWAYS_NEW flag to improve system performance. In that case, Broker uses the StoreNew operation without checking the code mapping table.

Time stamp order

You can use the time-stamp function to influence the order in which the components are accessed for loading existing data. For more information, refer to the section “Time stamp order” later in this chapter.

Two-phase commit and rollback

You can use operations such as PrepareStore and RollbackStore to ensure the consistency of compound transactions. For more information, refer to the sections “Two-phase commit protocol” and “Rollback” later in this chapter.

For more details and examples, refer to the document Scripting Language Reference (U7278E US).

Time stamp order If the same information is stored in more than one application, you can decide to make one of the applications leading, and synchronize the other applications from this originating component. However, sometimes you prefer to use whatever information is most recent.

Two components store address information. You want to synchronize the addresses based on the most recent information.

In that case, you can use the time stamps of the address records to determine which is the most recent.

To achieve loading and synchronizing in time-stamp order, take the following steps:

1 Open the editor for the logical data type.

2 Create a script to implement the GetTimestamp primitive operation for each component.

3 Select the Load Data in Time Stamp Order check box.

EXAMPLE



The GetTimestamp primitive is called for each participating component before retrieving a previously stored instance. The Broker loads the oldest data first, and the newest data is last. However, for the synchronize operation, the data from the originating component is always loaded last.

The following example provides a sample loading cycle:

Data is loaded from components A, B, and C.

Time-stamp ordering is active.

The following steps make up the loading cycle:

1 The component integration subsystem calls the Construct operation for A.

2 The Construct operation is called for B.

3 The Construct operation is called for C.

4 The GetTimestamp operation is called for A, which returns February 10, 2000.

5 The GetTimestamp operation is called for B, which returns March 1, 2000.

6 The GetTimestamp operation is called for C, which returns January 8, 2000.

7 The Load operation is called for C, because C had the earliest timestamp.

8 The Load operation is called for A, which had the second earliest timestamp.

9 The Load operation is called for B, which had the latest timestamp.

If you do no require timestamp loading, you can leave this primitive unimplemented.

Two-phase commit protocol A two-phase commit protocol helps to ensure the consistency of compound transactions. If you decide to use the two-phase commit protocol, the Broker calls the PrepareStore primitive operation for each participating component before calling the first Store primitive. You must provide an implementation for the PrepareStore primitive that performs the following tasks:

Request the component to prepare for the Store operation.

Check the data or the condition of the component on errors. For example, you can check whether a certain Number field is not zero, and you can check whether the component is ready to receive data.

If an error is found, the PrepareStore primitive must throw an exception.



If an exception is thrown in the PrepareStore operation, the following happens:

The Broker stops calling PrepareStore and Store. The store or synchronize operation that initiated the store cycle returns with

the exception.

The PrepareStoreNew and PrepareDelete operations are called before the StoreNew and Delete operations. These operations work in the same way as the PrepareStore operation.

To apply a two-phase commit protocol, take the following steps:


2 Create a script to implement the PrepareStore, PrepareStoreNew, and PrepareDelete primitive operations for each component.

3 Select the Store Data using a Two-Phase Protocol check box.

The following example shows an implementation of the PrepareStore primitive operation.

The component has a prepareTransaction method to prepare for various transactions. The method returns a negative value if an error occurs.

The Code variable contains the local code of the object. The second parameter indicates the type of transaction.

{

Exception e;

if ( Session.Interface.prepareTransaction (Code,

"UPDATE")< 0 ) {

e . code = Session.Interface.lastErrorCode;

e . reason = Session.Interface.lastErrorReason;

e . description = Session.Interface.lastErrorDescr;

// The store operation will be aborted.

throw e;

}

}

EXAMPLE



Rollback If an exception is thrown in the Store primitive in any component, the Broker will optionally call the RollbackStore primitive for any component that has previously completed its Store primitive successfully. Typically, RollbackStore undoes or reverses any changes made in the Store primitive.

Similarly, the RollbackStoreNew and RollbackDelete operations are called if an exception is thrown in the StoreNew or Delete operations.

To enable rollback, take the following steps:


2 Create a script to implement the RollbackStore, RollbackStoreNew, and RollbackDelete primitive operation for each component.

3 Select the Invoke Rollback if Errors occur when storing Data check box.



Primitive operations The component integration subsystem calls the Primitive operations to achieve direct interaction with external applications. If required, you must define the relevant script in the type editor to provide implementations for these operations for each component. The following table presents an overview of these operations.

Primitive operations Operation Description Construct The Construct primitive is called for each participating

component whenever a fresh instance of the type is created. The component can initialize any information in private or public data members.

GetTimestamp If time-stamp ordering is requested, the GetTimestamp primitive is called for each participating component before retrieving a previously stored instance. The component is expected to return the time and date when the component’s instance was last updated. (More details are provided later in this section).

Load The Load primitive is called for each participating component if the Broker must retrieve a previously stored instance.

Store The Store primitive is called for each participating component if the Broker must save (update) a previously created instance.

StoreNew The StoreNew primitive is called for each participating component if the Broker must create (insert) a fresh instance. If you assign a string value to the Code variable, the code mapping table is updated with information about this instance. (More details are provided later in this section).

Delete The Delete primitive is called for each participating component if you invoke the delete operation of the logical data type.

PrepareStore, PrepareStoreNew, PrepareDelete

These primitives are used if you apply a two-phase commit protocol, as explained in the section on two-phase commit protocol, earlier in this chapter.

RollbackStore, RollbackStoreNew, RollbackDelete

If an exception is thrown in the Store primitive in any component, the Broker will optionally call the RollbackStore primitive for any component that has successfully previously completed a Store primitive. The RollbackStoreNew and RollbackDelete primitives serve similar purposes. This concept is explained in the section on rollback, earlier in this chapter.

The printf function does not work in a primitive operation implementation, because the primitive scripts run on the server.

NOTE



Variables and parameters The following variables are visible in all primitive operations:

Session: Holds data about the logon session to the component. GUID: The object's globally unique identifier.

The Code variable holds the code by which the object is known in a particular component. In most of the primitive operations, this variable is available as an incoming variable. In other words, you can use the value of the Code variable in your implementation.

StoreNew

In the StoreNew operation, the Code variable is an outgoing parameter. The component is expected to return the code that is chosen for the new object. You must assign this code as a string value to the Code variable. The code mapping table is updated with this information. If you leave the Code variable as an empty string, no new record is inserted in the code mapping table. You can use this to control the size of the code mapping table, and to avoid crowding the table with unnecessary relations.

In the RollbackStoreNew operation, the Code variable is an incoming variable.

GetTimestamp

In the GetTimestamp operation, the Timestamp variable is an outgoing variable. The component is expected to return the time stamp of its instance in this variable. You must assign this value as a Time value to the Timestamp variable.

The GetTimestamp primitive is called for each participating component before retrieving a previously stored instance. If time stamp loading is not needed, this primitive can be left unimplemented.

Examples of primitive operation implementations This section provides several example implementations of primitive operations.

For example, suppose you define two components: Conf and EMail.

Component Conf contains a list of participants of a conference. The participants are registered in a table with the following String fields:

ParticipantNumber. Name. Category. EmailAddress.



You use an OleObject object to connect to Conf's COM interface. You entered \predef\system\OleObject in the component's Session type field.

You must use the following script in the logon script field of the component object to make the connection:

OleObject obj ("Conf.Participant");

Session = obj;

Now, you can access the methods and properties of the participants table as follows:

Session . method(); // Calls method() on the instance

Session . property = "ABC"; // Sets the property

String str = String (Session . property); // Retrieves the

property

Component EMail contains a directory of e-mail addresses. EMail is actually a simple database that is created in a ODBC-compliant database management system. The e-mail addresses are stored in a table with the following String fields:

ID. Name. EmailAddress.

You have defined the following objects in the repository:

\email\EmailRow. \email\EmailTable. \email\EmailFile.

EMailRow is a logical data type with the three fields of the EMail table. EMailTable is a table of EMailRow. The EMailFile file object is based on the EMailTable table type. This file object enables you to access the data.

You defined the PersonRow row type to represent a participant of the conference. Both Conf and EMail participate in this logical data type. PersonRow has the following String fields:

Name. Category. EmailAddress. strConfCode. strEMailCode.



The following examples show possible implementations for the Load, Store, and Delete operations.

The Code variable contains the local code of the object. The system retrieves this code from the code mapping table.

The Session variable stores a pointer to the component's COM interface.

Load (Conf)

The implementation of Conf's Load primitive operation:

{

try {

if (Code == "")

return; // Nothing to load if we don't have a code

// Session refers to the COM interface

if (Number (Session.OpenParticipant (Code .

asNumber)) != 0) {

strConfCode = Code;

Name = String (Session . Name );

Category = String (Session . Category);

EMailAddress = String (Session . EMailAddress);

}

}

catch (Exception e) {

printf ("Exception when loading PersonRow code

= %i, reason = %s", e.code, e.reason);

}

}

Load (EMail)

The implementation of EMail's Load primitive operation:

{

strEMailCode = Code;

\email\EMailRow emrow;

emrow = \email\EMailFile . find (ID == Code);

Name = emrow . Name;

EMailAddress = emrow . EMailAddress;

}



Store (Conf)

The implementation of Conf's Store primitive operation:

{

try {

if (Code == "")

return;

Session . ParticipantNumber = Code.asNumber;

if (Name . length() > 0)

Session . Name = Name;

if (Category . length() > 0)

Session . Category = Category;

if (EMailAddress . length() > 0)

Session . EMailAddress = EMailAddress;

if (!Number (Session . Update()))

printf ("Error in Conf Store");

}


printf ("Exception when storing Conf participant");

}

}

Delete

The implementation of Conf's Delete primitive operation:

{

try {

if (Code == "")

return;

Session.EraseRecord(Code);

}


printf ("Exception when deleting = %i, reason = %s",

e.code, e.reason);

}

}



Mapping objects You can define the transformations that you need to map data from one application to another by defining a mapping object. In a mapping object, you put all the information needed to transform one logical data type into another. For example, you can define a type that represents a product record in a Product Data Management system and another type that represents an item in a Warehouse Management system and define all the necessary mapping operations between the fields of these types in a mapping object.

Besides a mapping between two types, you can also define a mapping between a type and a mapper extension. The mapper extension connects directly to an application. For more information, see Chapter 1, “User-definable objects” in the Baan OpenWorld Broker Reference Guide (U7461B US).

Mapper extensions A mapper extension provides a direct connection with an application by means of one of the following methods:

ODBC database connection. COM class (not implemented in the current Broker version). Business Object Interface (BOI).

You can use the mapper extension in a component specification in a logical data type. The primitive operations of the type (Load, Store, and so on) will then be executed by the mapper extension.

You can also use mapper extensions in mapping objects.

For more information, see Chapter 1, “User-definable objects” in the Baan OpenWorld Broker Reference Guide (U7461B US).



Example using mapper extensions This section shows an example of synchronization of data from ERP to a SQL database table.

To set up the integration Use the following procedure to set the integration up:

1 Create two components, one for ERP and one for SQL. The ERP Component must have a component instance to be able to enter a connection string.

2 Define an ODBC data source for the SQL system. (Use the ODBC Data Sources tool in the Windows Control Panel).

3 Create a database connector that points to this data source.

4 Create two mapper extensions, one that uses the appropriate BOI and one that uses a database table.

5 Create a row type that represents the business object (the Business Object row). At this stage it is not possible to add a component to the Business Object.

6 Create a mapping object. The source of the mapping object is the ERP mapper extension. The target of the mapping object is the Business Object row.

7 Create another mapping object. The source of the mapping object is the Business Object row. The target of the mapping object is the ODBC mapper extension.

8 Edit the Business Object row and add components. One for ERP component where the mapping object uses the ERP mapper extension. The other component is then created for the mapping object that uses the ODBC mapper extension.



The process When you execute the row type’s synchronize operation with the ERP component as the originating component, the process is like this:

1 The integration subsystem calls load on the ERP component that uses a mapping object to load from ERP.

2 The load operation on the ERP mapper extension (class) is run which reads the data from ERP using the code that comes from the integration subsystem (code map table). The mapper extension creates a runtime row from the data in ERP and maps that to the Business Object using the mapper definitions in the Mapper object.

3 The integration subsystem calls the Store (or StoreNew) on the ODBC component that uses the mapping object to write to the ODBC.

4 The store operation in the ODBC mapper extension (class) is run. The mapper extension creates a runtime row and maps the data from the Business Object Row to the mapper extension runtime row. Then an insert (or update) SQL statement is created and executed on the database connector.

Code mapping Purpose The code mapping table translates codes (primary keys) between components. For example, the same customer can have the code JS in BaanERP, JSMITH in BaanFrontOffice, and 00.100.JSMITH in CODA-Financials. The code mapping table lets the Broker know that each of these codes pertain to one and the same customer.

If the component integration subsystem updates objects to the participating components, the subsystem uses the code mapping service to find the local codes of the object.

If the component integration subsystem stores a new object in a component, the component is expected to inform the Broker of the code that the component assigns to the object. This new code is automatically stored in the code mapping table. If an object is deleted, the code mapping table is also updated.

The code mapping service is also available to external applications through the IBaanCodeMapper COM interface. This feature is described in Chapter 15, “COM interfaces.”



Structure of the mapping table The code mapping table has the following columns:

Columns of the code mapping table Name Type Description Objguid String The globally-unique identifier (GUID) of the object. Component String The identification of the component. Subsystem String The identification of the subsystem within the

component that stores this object, for example, a table.

Code String The code of the object as defined in the component. To give an impression of a code mapping table, a part of a hypothetical code mapping table is shown here. This section of the code mapping table contains information about two different objects, which are stored in three different components.

Example code mapping table GUID Component Subsystem Code {FCA1116E-1D99… BAANERP TCIBD010 JS {FCA1116E-1D99… BFO CUST JSMITH {FCA1116E-1D99… CODA-FIN A 00.100.JSMITH {FCA13174-1D99… BAANERP TDSLS010 TJ {FCA13174-1D99… BFO CUST TJOHNSON …

GUID Every instance of a logical data type automatically receives a system-generated globally unique identifier (GUID). The GUID can be used as a component-neutral identifier and a source for mapping into component-specific codes. GUIDs are defined and standardized in the X-Open Distributed Computing Environment (DCE) specifications. A GUID is a 32-byte code that is guaranteed to be unique across the universe.

A GUID is only associated with an object if the object was originally stored by means of the synchronize or storeNew operation. These operations are described in the section “Logical data types and components,” later in this chapter. These operations automatically update the code mapping table.



Operations The code mapping table has a number of operations that you can access by means of the scripting language. The following table shows these operations.

Integration-specific operations of types and values Operation Description add Creates a new row in the code mapping table.

The following conditions are checked: For each combination of component and subsystem, every code must be unique. Every object (GUID) can occur only once in every component.

map Returns the code in the target component. The input parameters can be the object's code in another component or the object's GUID.

modify Modifies an object's code in a component. remove Removes one row (the object code in a particular component) or

all rows that pertain to a specific object. For more information, see the description of the CodeMap object in the document Scripting Language Reference (U7278E US).

You must be careful if you modify the code mapping table directly. The operation of the component integration subsystem depends heavily on the integrity of the code mapping table.

If the Subsystem field in a logical data type definition is left blank for a specific component, no code mapping is performed for that component.

Technical details The code mapping table is stored in a relational database and manipulated through a database connector object defined in the object repository. Any ODBC-compliant database is supported.

The code map table is created automatically, as long as there is a database connector object called \sys\databases\cis that specifies a valid ODBC source. In \predef\system, two types, CodeMapRowType and CodeMapTableType, specify the attributes of the code map table.

For more information, refer to the section “Database connectors” Chapter 1 in the Reference Guide.

For the COM interface to the code mapping table, refer to Chapter 15, “COM interfaces.”

NOTE

NOTE



Iterators Iterators are used for fast bulk synchronization of data between a single originating component and multiple destination components. Iterators are usually applied in batch processes that run at regular intervals to synchronize the data between applications (components).

The synchronize operation on a logical data type runs load and store operations on a record-by-record basis. The synchronize operation of an iterator gives you more flexibility and potentially a better performance. For an example, see the ‘Synchronization in a batch process’ case in the “Example cases” section, earlier in this chapter.

For more information, refer to “Iterators” in Chapter 1 in the Reference Guide.

Communication mechanisms You can apply several different communication mechanisms, synchronous as well as asynchronous. These mechanisms are described in other chapters.

COM Automation

For information on the use of Microsoft COM Automation objects, refer to the description of the OleObject class in the Scripting Language Reference (U7278E US).

BaanERP BOIs

If you use the Baan OpenWorld Enterprise Connector wrappers, you can access BaanERP Business Object Interfaces (BOIs) as OleObjects.

Messaging

For information on the use of the Broker's messaging system, see Chapter 9, “Messages.” Protocols such as POP3 and SMTP are supported.

Internet

The Internet protocol http is available through the Baan OpenWorld Broker's Internet object. For more information, refer to the “Internet object” section in the document Scripting Language Reference (U7278E US).



Direct database access

You can obtain direct access to tables in ODBC-compliant databases by means of Database connector objects and File objects. For more information, refer to “Database connector” and “File” in Chapter 1 in the Reference Guide.

DLL proxies

For information on access to DLLs on your client PC, refer to “DLL proxy” in Chapter 1 in the Reference Guide.

COM Interfaces

For information on the use of the Broker's COM interfaces by external applications, see Chapter 15, “COM interfaces.”


Introduction This chapter describes the Baan OpenWorld Broker's messaging facilities. These facilities can be divided into the following groups:

Facilities for automatic handling of incoming messages. Facilities for sending messages to applications. Facilities for sending e-mail. Facilities for sending messages to users who are connected to the Broker.

Message objects The facilities for automatic handling of incoming messages, and for sending messages to users, are based on message objects. A message object contains an Broker value, for example, a string or an instance of a row type. The message object can also hold information regarding the object’s sender, recipient, a subject, and so on. Usually, messages for automatic processing are stored in a message queue folder and messages for manual processing are stored in a user's mailbox.

To handle incoming messages

Purpose The Broker can receive and act upon a wide variety of signals and messages from outside sources. This messaging system plays an important role in the Broker's integration capabilities.

For example, you can:

Listen for notifications of data changes from external applications. Upon such a notification, a synchronization cycle is initiated to update all applications that share this data.

Feed information from front-end systems, for instance, in local branches, into the back-end financials through the Microsoft Message Queue Server over the Internet or over leased lines.

9 Messages

Messages


Enable users to send e-mail to the Broker to initiate or control workflows.

For more examples, refer to “Example cases” in Chapter 8, “Component integration.”

Supported technologies The following message transports are supported:

Internet e-mail (POP3/MIME, SMTP). File Transfer Protocol (FTP) Hypertext Transfer Protocol (HTTP) Operating system files. Microsoft Message Queues (MSMQ). AMI message (for example, IBM MQSeries).

The following types of message encoding can be handled:

Plain text strings. XML documents. BizTalk Framework.

The architecture is extensible through Microsoft’s COM to support user-defined message formats and transports.

For detailed information, refer to the Reference Guide, Chapter 6, “Message translators” and Chapter 7, “Message transports”.

Actions To handle a message that is received and translated, the Broker uses any of the facilities of the objects in the repository, or uses the scripting language. You can define the response to messages by means of the action wizard. Example actions are:

Send an e-mail. Send a Broker message. Run a script to initiate a synchronization cycle.

For more information, refer to “Action wizard” in Chapter 10, “Tools and assistants.”

Messages


Procedure Message sources, message queues, and message handlers all handle incoming message as follows:

Message source objects define how to retrieve and handle incoming messages.

Message queue objects enable the Broker to buffer incoming messages until a message handler is free to deal with these messages. Queued messages are stored in a folder in the object repository.

Message handlers pick up messages of a particular logical data type from a queue in the object repository and perform an operation on the messages.

For detailed information, refer to see the corresponding sections Chapter 1 in the Reference Guide.

The following list describes the procedure to process an incoming message:

1 A message source looks for messages when the its poll operation is called.

2 The message source receives the available messages through its transport layer.

3 The message source puts each incoming message through a message translator.

4 The message source’s translator parses the incoming message stream and creates a meaningfully typed Broker value.

5 The message source packages the value inside a message object and stores the value in a message queue in the object repository. A message queue can contain messages of multiple types.

6 A message handler connected with the message queue picks up messages of a specific logical data type. The message handler is activated when its poll operation is called.

7 The message handler executes a specified action for each message the message handler picks up.

To send messages to applications In the action wizard, you can push a Broker value to a message sink. The Broker value can be a text string or a value of a row type, or any other type. The message sink translates the value to an appropriate format, for example, an XML document, and sends the message over a preconfigured message transport.

Messages


The message sink can store messages in an optional message queue to improve performance.

Facilities for sending e-mail In the action wizard, you can define an action to send an e-mail message.

You can also use the scripting language; the String class has two operations that you can use to send e-mail messages:

sendMail. sendMAPI.

To send e-mail, you must specify the SMTP server and some related data as follows:



3 Right-click the Server Broker icon.

4 In the drop-down menu, click Properties.

5 On the Internet tab, specify a legal SMTP mail server, the full name of the e-mail sender, and the e-mail account, in the format [email protected].

6 Enter the remaining fields if relevant.

For information on these operations, refer to “String::sendMail” and “String::sendMAPI” in the Scripting Language Reference (U7278E US).

To send messages to users The Broker enables you to send messages to internal users. A message contains an instance of a logical data type. Examples of such instances are:

A String type that contains plain text. A row type, for example, a purchase request. A table type, for example, a list of customers.

The Broker's workflow system uses such messages to transfer documents to the users for further handling.

You can define an action to send a message to an internal user or a user group by using the action wizard.

Messages


You can also use the scripting language. The User class has a sendMessage operation and the Query class has send and sendTo operations.

In general, if you use the sendMessage operation to send the message, the procedure is as follows:

1 A script calls the sendMessage operation on a user object. The parameters of the sendMessage operation specify the value that is sent and the form is used to display the message.

2 The sendMessage operation packages the value in a message object. The message object contains a reference to the form and information about the sender, recipient, date and time of dispatch, and so on.

3 The message is put in the user's mailbox folder.

4 The user is notified that new mail has arrived.

5 If the user clicks Read now, the message is displayed by the associated form.

Mailbox

The user's mailbox folder is automatically created if the user receives messages. The mailbox folder is \sys\mailboxes\USERNAME, where USERNAME is the identifier of the user, which is the name of the user object.

To open your mailbox, on the Baan OpenWorld Broker menu, click Mailbox.

This menu is contained in the Broker's default menu. This menu is not visible if the repository browser is open. The menu command opens the predefined form \apps\misc\forms\Mail, which contains a Mailbox type input field.

You can also send messages to user groups.

For more information, refer to the sections “Message”, “User,” “UserGroup,” and “Query” in the Scripting Language Reference (U7278E US).

NOTE

Messages



Application development is facilitated by a number of powerful tools. The following table lists these tools, and the tables are then further explained in the following sections.

Tools, helpers, and assistants Tool Description Tool dock A window that contains the expression tool, fields tool, fonts

tool, and the color tool. Expression tool A tool in which you can enter and test a scripting language

expression. Fields tool A tool to add fields to forms. Fonts tool A tool to select and apply font styles to texts. Color tool A tool to mix and store colors and to apply colors to objects. Action wizard A wizard that helps you to define automated actions, such as

automatic sending e-mails, starting workflows, or starting periodic processes.

Type assistant A tool that helps you to select a type. You can select either a user-defined type from the repository or a predefined primitive type (Number, String, and so on).

Expression assistant

A tool that helps you to enter valid expressions.

Script assistant A tool which enables you to enter a script and, under certain circumstances, test and debug the script.

Tool dock The tool dock contains four tools that can help you to design Broker objects:

Expression tool. Fields tool. Fonts tool. Color tool.

These tools are described in the following sections.

To open the tool dock, on the File menu, click Open Tool Dock.

You can also find the Open Tool Dock menu command on the repository browser's Objects menu.

10 Tools and assistants

Tools and assistants


Expression tool In the expression tool, you can enter and evaluate a scripting language expression. Example expressions include:

12+3. \users\SUPERUSER.edit. System.queryTime.

The expression tool contains a history list. To enter an expression that you typed before, click the drop-down arrow next to the expression field and click an expression on the history list.

Click Expression assistant to open the expression assistant. The expression assistant is explained later in this chapter.

Fields tool If you edit a form that is linked to a row type, the field tool displays a list of fields that you can drag onto the form. The use of the fields tool is explained in “Form” in Chapter 1 in the Reference Guide.

Fonts tool You can use the fonts tool to change the text styles of text boxes, as follows:

1 Open the tool dock and a form.

2 Configure a font style in the fonts tool.

3 Drag from one of the four shadowed T icons to the Preview field to add a shadowing effect, if desired. To remove shadowing, drag from the top, unshadowed, T icon.

4 Click on the sample in the preview window, and drag the sample onto any text box or onto a tab of a background query. The type changes accordingly.

Color tool You can use the color tool to quickly apply color to many elements of an object and to the background of some windows. The elements that you can apply color to are mostly those used when you create a form.



Named colors

You can give arbitrary names to colors, for example, BackgroundColor or AttentionColor. If you use named colors, you can more easily maintain a consistent color scheme. For example, if you change BackgroundColor from green to a yellowish color, all objects with that color then change appearance.

Applying colors to objects

To apply a color, take the following steps:

1 Open the Tool Dock and a form object.

2 Drag any color out of the Color tool and drop the color over the background of a window or over an object. If the mouse pointer comes at a point where you can drop a color, the mouse pointer changes to a paint roller.

Several additional options are available for you to use to change the color of a text box on a form:

You can drop a color on a text box in one of the following three ways:

Simply drag the color to change the background color of the text box.

Hold down SHIFT while you drag a color onto some text to change the text’s foreground color.

Hold down CTRL while you drag a color onto some shadowed text to change the color of the text shadow.

You can also color the tabs of background queries in the same way, changing their background, text, and shadow.



To mix colors

You are not limited to the colors supplied on the Color tab of the Tool Dock, but can mix your own.

To mix a new color, take the following steps:

1 Open the Tool Dock.

2 Select the Color tab.

3 Drag a color to the mixing tank.

4 Change the color with the red, green, and blue slider controls until you have the color you want.

You can now:

Drag and drop the color onto an object to apply the color. Drag and drop the color onto one of the cells on the Color tab to store the

color for future use. Create a named color. For more information, refer to “Named colors,” later in

this chapter.

Named colors

The definition of named colors enables you to more easily maintain a consistent color scheme. For example, you can define a collection of named colors:

BackgroundColor. BorderColor. MainText. WarningText. TextShadow.

If you later change the color of a named color, all the objects to which you applied that named color will be changed accordingly.



The following table explains the use of named colors.

The use of named colors If you want this Do this Define a named color 1 Create a color in the mixing tank as described in

“Mixing colors,” earlier in this chapter. 2 Enter a name for the color in the text field and click Plus (+) to store the color with the name.

Apply a named color to an object

Drag the color from the mixing tank to the object (background, text box, and so on). Use the SHIFT key to apply a color to the foreground of a text and the CTRL key to apply a color to a text shadow.

Load a named color back into the mixing tank.

Select the name of the named color in the text box.

Change the color of a named color

1 Load the named color in the mixing tank by selecting the color’s name from the drop-down list.

2 Change the color with the slider controls. 3 Click Plus (+) to save the changes.

Delete a named color 1 Select the named color from the drop-down list. 2 Click Minus (-). The color is deleted from the system.

Action wizard

Function of the action wizard If one of the following situations occurs, the Broker must respond with a certain action:

A user clicks a button on a form. A user clicks a menu command. A value that is monitored by an alerter becomes higher or lower than the

prescribed bounds. A message handler receives an incoming message.

You must specify the appropriate action when you define the form, menu, alerter, and message handler objects that handle these situations. If you must define such an action, the action wizard appears automatically.



In the action wizard, you can select one of the following types of action:

Send e-mail. Start workflow. Send Broker message. Run script. Display form. Start periodic process. Evaluate timed variable. Do nothing.

After you select the type of action, the action wizard prompts you for any information that is required to execute the action, for example, an e-mail address.

Macros in e-mails If you specify that an e-mail must be sent, you can use the following macro codes in the subject and in the message text:

%DATE% for the current date. %TIME% for the current time. %VALUE% for a value, for example, the current value of an alerter. %PREVVALUE% for the previous value, which can be useful in alerters. %<any expression>% for the expression result.

The Broker will expand the macros before sending the message.

Variables If you press the Run script action for a form button, you can use the special variables for forms:

Page. Value. State.

The operations of the View object are also available. For more information, refer to “Forms” in Chapter 1 in the Reference Guide.

If you select the Run script action in a message handler object, you can access the value contained in the message by means of the ‘this’ variable.



Type assistant If you must enter a logical data type in a field, you often find the icon for the type assistant next to the field. You can click this icon, or press F4, to open the type assistant. You can select a type in one of two ways:

Click a user-defined type in the tree view of the repository.

Click a button to select a predefined primitive type, such as Number, String, and so on. You can find additional predefined types in the \predef\system folder.

Click Close to accept the selection.


User objects For each user that accesses the Baan OpenWorld Broker, a user object must exist in the \users\ folder.

The functions of user objects are:

Control access rights.

Configure the user environment.

Identify the person that performed certain actions. For example, the version control system records which developer locks or modifies an object. The logging system records the user that initiated an event.

Enable the system to send messages to users.

Distribution of documents in the workflow system.

To group users, you must define user groups. User groups can contain other user groups. In this way, you can set up a hierarchical structure of users. You can use user groups as distribution lists for messages.

The Users dialog box provides a convenient way to create and modify user objects. To open the Users dialog box, on the Baan OpenWorld Broker menu, point to Settings, and click Users on the submenu.

You can configure user objects by using the Broker Configure tool:

1 Start the Broker Configure tool.

2 In the tree view, select the Users folder under Broker.

3 Select a user and modify the properties in the list view.

When you select another object or close the current folder or the Configure tool itself, the Configure tool asks you if you want to save the changes.

You can change the user properties, but you cannot create or delete user objects in the Configure tool.

For detailed information, refer to “User” and “User group” Chapter 1 in the Reference Guide.

11 User management

User management


To log on If your Broker client is configured for trusted logon, you can start the program without entering a user name or password. The system uses your Windows NT user name as user identification.

If you log on to the system for the first time, and your Windows NT user name does not exist in the \users\ folder, the Broker will automatically create a user for you. Automatically created users do not have superuser status.

To log on with a different user identification or password, you must configure your Broker client to start without trusted logon.

To configure your Broker client, take the following steps:



3 Right-click the Client Designer icon.

4 In the shortcut menu, click Properties.

5 On the Basics tab, select or clear the Enable trusted logon check box.

After you log on, the Broker sets up the user environment that is linked to your user object.

Access rights The Broker uses the passwords of user objects to control access to the system. The user object has two options to differentiate access rights:

Superuser. VCS access.

Superuser

Only users with superuser status can create and modify objects. Users who are not superusers cannot open the repository browser, and cannot right-click an object to open a shortcut menu. You must have superuser status before you can change the superuser status of any user. The Broker contains a predefined user object SUPERUSER. After you install the system, you can use SUPERUSER to grant superuser status to other user objects.

User management


VCS access

A user with VCS access can modify version-controlled objects. For more information, refer to Chapter 13, “Version control system.”

User environment You can link each user to an environment object. The environment object controls the entire user environment, including:

The language of the user interface. The shortcut menus. The queries shown in the background of the main window. A query can

contain pictures, data fields, buttons, and so on.

You can also use the environment to start a script whenever a user logs on, or to start periodic processes.

Environments can inherit the attributes of other environments. For more information, refer to “Environment” in Chapter 1 in the Reference Guide.

User management



Introduction The Baan OpenWorld Broker can display texts in the user interface in multiple languages, depending on the settings of the user. If you want to use this feature, you must take the following steps:

1 Enter descriptive texts in multiple languages.

2 Enter the locale of the user.

The texts that can occur in multiple languages are called locale strings.

The system recognizes locales for many languages and countries, for example, Español – Argentina. In addition to the locales for specific languages, the system has a special locale named Default. If the system cannot find a text string for a specific locale, the system always displays the text for the Default locale.

Translation

You can export all locale strings to a text file for easy translation of the user interface.

To enter texts in multiple languages Multilanguage fields

You can enter locale strings in multilanguage fields. Many objects have multilanguage fields, for example:

Description fields, such as the description of a form. Menu items in menu objects. Text fields on forms.

You can recognize multilanguage fields by the globe button next to the field. If you enter text in a multilanguage field, you can open the language-independent input box as follows: press F4 or click the globe icon.

If you enter a text directly in a multilanguage field, the string will be stored under your current user locale.

12 Language support

Language support


Text tables

If you work with strings in expressions, you can use language-independent text tables. In a language-independent text table you can store many locale strings, that you can use in scripts and expressions.

Example situations where you can use text tables are:

Error messages displayed by calling the printf function in the scripting language.

Expression fields on forms.

For more information about text tables, refer to “Text table” in Chapter 1 in the Reference Guide.

To set the user language To set the user language, you must specify the appropriate locale in the user object of that user or in the environment object to which the user is linked. The language specified for the user usually overrides the environment language. However, if the user’s language is set to Default, the environment language is used.

If a user logs on to the Broker, the system displays all the locale strings in the locale of the user.

To open a dialog box to change the current language, you must call the setLanguage method of the Environment object. For more information, refer to the document Scripting Language Reference (U7278E US).

For more information, refer to the sections “User” and “Environment” in Chapter 1 in the Reference Guide.

Text export To make the translation of the user interface easier, you can export the locale strings to a text file. The overall procedure is as follows:

1 Export the locale strings in the source language to a text file.

2 Translate the strings in the text file.

3 Import the translated strings in the locale of the target language.

Language support


To export locale strings, you must use the following procedure:

1 Start the Tool Dock.

2 Enter the following expression in the Tool Dock's Expression tab: Archive . exportLocaleStrings

3 Click Evaluate. The Export Locale Strings to File dialog box opens.

4 Enter a valid path and file name in the Name field for the file that will store the exported locale strings. The file automatically receives the extension txt.

5 Add or remove objects from the Objects to export strings from list, until you are satisfied with the resulting selection.

6 Select the locale that must be exported.

7 Click OK.

Tip

To make operations such as this more readily available to you, you must put these operations in a menu. For more information, refer to “Menu” in Chapter 1 in the Reference Guide.

The procedure to import the translated strings is similar to the export procedure:


2 Enter the following expression in the Tool Dock's Expression tab: Archive . importLocaleStrings

3 Click Evaluate. The Open dialog box opens.

4 Select the file containing the locale strings that you want to import.

5 Open the Locale list and select the language that you want to import.

6 Click OK.

Language support



Introduction The version control system (VCS) controls the versions of objects during the development process.

Purpose Using a VCS has the following advantages:

The VCS contains a sort of archive of old versions of objects. You can view the history of objects and restore older versions. All the old object versions are saved until you explicitly discard them.

The VCS facilitates cooperative development. If one developer is editing an object, the other developers can continue to use the existing version of the object. After a developer completes the editing of an object, the updated object is made available to all others.

The VCS enables you to put a label on the current version of a collection of objects. Later, you can export the labeled version of these objects. You can also return the objects to the state the objects had when they were labeled.

Check out and check in The VCS uses a check-out/check-in mechanism. A developer who wants to work on a version-controlled object must first check out the object. After the developer is satisfied with the changes, the object must be checked in again.

A version-controlled object that is not checked out cannot be changed by anybody. An object that has been checked out can be edited and modified at will, but only by the user that performed the check-out operation. Other users can still use the existing version of the object. After the object is checked in, the new version is available for all users.

User A wants to add two fields to a form. The user checks out the form, adds the fields, and modifies several scripts in the form. The user can test the modified form while it is still checked out. If the result looks good, the user checks in the updated form. Thanks to the VCS system, the other users can continue to use the form. The user will see the old version, until user A checks the form in again.

13 Version control system

EXAMPLE

Version control system


External version control systems You can integrate Broker with external configuration management tools, such as Microsoft SourceSafe and Continuus. This integration uses Broker's XML import and export function. You can configure Broker to maintain an XML representation of every object in a shadow repository in a local system folder. In this way, you can use a configuration management tool to maintain version control.

For more information, see the Reference Guide, Chapter 9, "XML import and export".

To set up the VCS User data To give a user access to the VCS, you must edit the User object as follows:

Select the VCS check box in the User dialog box.

Only users with the appropriate access permissions can use the VCS. Users must be superusers before they can be given access to VCS. Users without access to the VCS can view the version-controlled objects, but they cannot change the objects.

Object information To make an object version-controlled, you must edit the object information as follows:

1 Select an object in the object browser.

2 On the Objects menu, click Info. The object information dialog box opens.

3 On the Flags tab, select the Enable Version Control check box.

If you clear the Enable Version Control check box, the previous versions are discarded and you lose all version information.

NOTE



Multiple objects

To enable the VCS on multiple objects in a single folder, take the following steps:

1 Select the objects in the object browser.

2 Right-click one of the selected objects.

3 On the Version Control submenu, click Enable Version Control.

If you do not see the Version Control submenu, you do not have access to the VCS.

Objects that cannot be version controlled are ignored. A folder cannot be version controlled. The Enable Version Control option only affects the objects that are selected directly. The option does not affect the objects inside a selected folder.

You can enable version control on multiple objects from any number of folders or even the entire object repository in a single action by using The Change Object Storage Flags dialog box.

You can display this dialog box by means of the setFlags operation of the Archive object. This operation has the following specification:

VOID Archive::setFlags (VOID)

To open the Change object storage flags dialog box, take the following steps:


2 Enter the following expression in the Tool Dock's Expression tab: Archive . setFlags

3 Click Evaluate.

4 In the Change Object Storage Flags dialog box, add or remove objects from the Objects to change list, until you are satisfied with the resulting selection.

5 Select the Set Version Control System Flag check box.

6 Select the Version Control System check box.

7 Click OK.

Tip

To make operations such as this more readily available to you, you can put these operations in a menu. For more information, refer to “Menu” in Chapter 1 in the Reference Guide.



VCS object

If an object enters the VCS, a VCS object is created in the VCS system folder, \sys\vcs. A VCS object has a unique name, which starts with the prefix VCSO. The system uses VCS objects to store information on versions for specific objects. You must not edit or delete the objects in the VCS system folder.

Objects not under version control As long as an object is not placed under version control, the object can be edited without restrictions. Older versions of the object are not stored.

Several types of objects cannot be version controlled, for example, documents, messages, and system objects.

To view information about version-controlled objects If an object is version controlled, you can view the following information on the VCS tab of the repository browser's object information box:

The lock status and the related lock description. The check-out status, and when and by whom the object was checked out. The number of stored versions.

To find detailed information about stored versions, you can use the Show history command. To use this command, take the following steps:

1 Right-click an object in the object browser.

2 On the Version Control shortcut menu, click Show History.

3 Select a version.

4 Click Details to display any check-in comments for a version.

The Show History dialog box shows every version of the object and several actions that were performed on the object.

The Created action indicates when an object becomes version controlled, not the creation of the object itself.

NOTE



Check out, check in, undo check out A version-controlled object must be checked out before it can be edited. Only the user that checked the object out can edit it.

Check out

To check out an object or a group of objects, take the following steps:

1 Select one or more objects in the object browser.


3 On the Version Control submenu, click Check out.

The selected objects are checked out.

Check in

If you are finished editing, you must check the object in. The newly-edited version becomes the current version, which is available to other users. If you check an object in, you must enter a short description of the changes.

To check in an object, click Check in on the Version Control submenu.

The old version is stored in a compressed format in the VCS system folder, \sys\vcs. Old versions are stored as a file whose name starts with the prefix VCSV. You can still access an old version by using a get or rollback operation.

Undo check out

If you do not want to save the changes that you have made to a checked out object, you can use the Undo check out operation. The existing version of the object is left intact and the checked out version is discarded.

To undo a check out, click Undo Check out on the Version Control submenu.



Locking No user can delete, edit, or change an object that is locked. A locked object cannot be checked out until the object is unlocked. Users with access to the VCS can unlock any object—even the objects that were locked by other users.

Locking can be useful if you are working on objects that are dependent on a number of other objects. This is explained in the following example.

You are working on forms that depend on a number of logical data types. You do not want anybody to change these logical data types while you are still working on the forms. In this case, you can lock the logical data types.

Lock

To lock an object or a group of objects, take the following steps:



3 On the Version Control submenu, click Lock.

4 Enter a description of the reason for locking the object.

The selected objects are locked.

The lock description is displayed on the VCS tab in the repository browser's Object Information dialog box.

Unlock

To unlock an object, on the Version Control submenu, click Unlock.

Labels

To put labels on objects To keep track of object versions, you can put a label on a version. This action is especially useful if you put a label on all objects that belong to a certain application or subsystem. After you label the objects, you can recreate the historic version of the application or subsystem exactly as the version was on the date and time of labeling.

EXAMPLE



For best results, you must label your objects regularly during the development process, because you cannot put labels on older versions afterwards.

After you use a certain label, you can no longer place the same label on other objects. You cannot add objects to an existing label.

To label an object or a group of objects, take the following steps:

1 Make sure that all objects that must be labeled are checked in. You cannot label objects that are checked out, but you can label locked objects.



4 On the Version Control submenu, click Label.

5 Enter a string in the Label Object dialog box. You must enter a string that has not been used as a label before.

6 Click OK.

Label multiple objects

To label multiple objects from any number of folders, or even the entire object repository, in a single action, use the Label Objects dialog box. To start this dialog box , you can use the multiLabel operation of the Archive object. This operation uses the following syntax:

VOID Archive::multiLabel (VOID)

To open the Label Objects dialog box, take the following steps:


2 Enter the following expression in the Tool Dock's Expression tab: Archive . multiLabel

3 Click Evaluate.

4 In the Label Objects dialog box, add or remove objects from the Objects to Label list, until you are satisfied with the selection.

5 Click OK.

Tip

You can make operations such as this more readily available to you by putting these operations in a menu. For more information, refer to “Menu” in Chapter 1 in the Reference Guide.

NOTE



Technically, a label is stored as a version that is identical to the label’s predecessor.

To use labels You can perform the following actions on labeled object versions:

Export the objects to a file. For more information, refer to “Export and import” in this chapter.

Make the labeled object version the actual version. For more information, refer to “Restore old object versions” later in this chapter.

Permanently remove the labeled version and older stored versions from the VCS. For more information, refer to “Discard old object versions” later in this chapter.

You can execute these actions by means of the Export Labelled Objects to File dialog box. This dialog box is started by means of the exportLabel operation of the Archive object. This operation uses the following syntax:

VOID Archive::exportLabel (VOID)

To open the Export Labelled Objects to File dialog box, take the following steps:


2 Enter the following expression in the Tool Dock's Expression tab: Archive . exportLabel

3 Click Evaluate.

Tip

To make operations such as this more readily available to you, you can put these operations into a menu. For more information, refer to “Menu” in Chapter 1 in the Reference Guide.



Restore old object versions

Get If you use the Get command, you can retrieve an old object version and make the version the current version. All other versions are left intact. In other words, you put the selected object version on top of the object stack. You have two different Get commands:

The Get command for a single object. The Get command that works on all objects with a certain label.

To use the Show History command to perform a Get operation on a single object, take the following steps:


2 On the Version Control submenu, click Show History.

3 Select a version.

4 Click Get.

To perform a Get operation on all objects with a certain label, you must open the Export Labelled Objects to File dialog box. The “Labels” section later in this chapter describes how you can open this dialog box. To retrieve this version, select a label and click Get.

Rollback The Rollback command restores an older version of an object, and discards all later changes. Use this command with caution, because you cannot undo this command. To perform a Rollback operation, take the following steps:


2 On the Version Control submenu, click Show History.

3 Select a version.

4 Click Rollback.



Export and import Impact of VCS on export and import The export operation does not export any version information. If you import objects, the imported objects are initially not version controlled.

You can import an object over an existing version-controlled object if the following conditions are met:

The object is checked out. The object is not locked.

Export labeled objects To export all objects in the repository that are identified by a certain label, take the following steps.

1 Open the Export Labelled Objects to File dialog box.


3 Enter the following expression in the Tool Dock's Expression tab: Archive . exportLabel

4 Click Evaluate. The Export Labelled Objects to File dialog box opens.

5 Enter the path for the export file.

6 Enter the name of the export file.

7 Select a label.

8 Click Export.

For more information on exporting and importing, see Chapter 8 in the Reference Guide, “To export and import objects.”



Discard old object versions If you are sure that you no longer need old object versions, you can delete the versions to save space. To delete old versions, take the following steps:

1 Open the Export Labelled Objects to File dialog box (see previous section).

2 Select a label.

3 Click Discard.

The Discard command deletes the versions with the specified label as well as all older versions. If older labels exist, you must also discard these labels to save the space that is taken up by these labels.


Introduction The Baan OpenWorld Broker logs several types of events in a database. For example, an error that occurs during database access, or the receipt of a message.

The logging system can be used to investigate what has happened in the system. Among others, the logs can be used by the following users:

Help desk employees who offer customer support. Developers who debug applications. System administrators who investigate the performance of the system or

maintain security.

14 Logging system

Logging system


You can specify in a very detailed way which events must be logged. If the Broker is released, logging is turned off. You can turn logging on in the server configuration utility. The logging system maintains logs for several subsystems, as indicated in the following table:

Logging subsystems Log code Subsystem Events sys System Logging on to the system. Use of a wrong

password. Selection of menus by users. cis Component

integration Exceptions and other events in the operations defined in logical data types, for example, the primitive operations Load, Store, and so on. Errors in the execution of iterators.

odbc Database connections (ODBC)

The events are logged in database tables in ODBC-compliant database systems, for example, Microsoft SQL Server. If you do not use a database, for example if the database connectors have been deleted, the logging system logs the events in text files on the server's working directory. If the database connection of the logging system fails, an event is logged in the Windows NT event log.

periodic Periodic control Events associated with running alerters and periodic processes, and recalculating timed variables.

inet Internet and e-mail Events related to the Internet and the e-mail system.

msg Broker messages Events related to the message queue. com COM/OLE Events related to the use of the Broker's

OleObject class to access Microsoft COM Automation objects.

You can add user-defined logs to the logging system.

The events are logged in database tables in ODBC-compliant database systems, for example, Microsoft SQL Server. If you do not use a database, for example if the database connectors have been deleted, the logging system logs the events in text files on the server's working directory. If the database connection of the logging system fails, an event is logged in the Windows NT event log.

Use a dedicated database to store the logging tables. A desktop database product like Microsoft Access does not suffice. A stronger engine, such as SQL Server 7 or Oracle, is recommended to maintain OpenWorld Broker tables, including the bis_objrelations table.

IMPORTANT

Logging system


The workflow system has an individual logging system which records events related to documents.

Error levels

Three error levels are distinguished:

Critical error. Noncritical error. Warning.

You can also log successful operations, for example, the successful execution of a Load operation.

For more information, see Chapter 14, “Logging system” of the Reference Guide (U7461B US).

The Log viewer The Broker Log Viewer enables you to view, filter, and delete the various logs. The Log viewer is a separate program that is installed together with Broker. Use the Broker Configure tool to configure the Log Viewer.

Logging system



Introduction

Purpose of the COM interfaces To expose services to COM clients, the Baan OpenWorld Broker uses COM interfaces. A COM interface enables external programs access to the objects in the object repository. You can create a program, for example, in a Microsoft Office application, to execute an operation from an object in the repository.

After you establish a logon session and a connection to the repository, you have a number of possibilities:

Evaluate expressions, which offers you all the power of the scripting language.

Create and manipulate instances of logical data types.

Access objects and folders to retrieve information about objects. In this release of the COM components, objects are read-only.

Use the code map to translate object codes between integrated applications. For example, you can translate the supplier code in one application to a business-partner code in another application.

The Broker’s COM interfaces are described in a separate document: Baan OpenWorld Broker COM Interfaces.

COM Automation

This chapter describes how external applications can access the functions of the Broker. The opposite is also possible. You can use the operations of the OleObject class in the Broker's scripting language to access Microsoft COM Automation objects. For example, you can address a cell in a Microsoft Excel spreadsheet. The OleObject class is described in the document Scripting Language Reference (U7278E US).

15 COM interfaces

COM interfaces


Overview example The following example in VBA gives you a quick idea of how you can use the Broker's COM components to access the repository and the objects in the repository.

This section describes the details for each interface.

To connect to the repository

The following example shows how you can set up a connection with the repository.

‘ Create a new instance of the BaanIntegrationServer

‘ class:

Dim Server As New BaanIntegrationServer

‘ The IP address and port of the Repository server:

Server.Address = "10.2.59.235:7250"

‘ Create a BaanConnection object to represent

‘ a logon session and logon:

Dim Conn As BaanConnection

Set Conn = Server.LogonAsUser("UserName", "Password", "")

‘ Connect to the repository

Dim Rep As BaanRepository

Set Rep = Conn.Repository

Expressions

The following code fragment shows how you can evaluate an expression.

Dim strResult As String

strResult = Conn.Evaluate ("Time () . asString ()")

Repository objects

The following code fragment shows how you can access an object.

‘ Fetch an IBaanObject interface on an object

‘ stored in the repository:

Dim obj As BaanObject

Dim strName As String

strName = "\MyObject"

obj = Rep . Object (strName)

COM interfaces


Logical data types

The following example shows how you can work with types and values.

‘ Create a BaanType object:

Dim MyType As BaanType

Set MyType = Rep.Object ("\MyType")

‘ Create a new instance of this type:

Dim MyValue As BaanValue

Set MyValue = MyType.New ()

‘ Load the instance with code "010" from the

‘ "BAANERP" component:

Dim MyOtherValue As BaanValue

Set MyOtherValue = MyType.Load ("BAANERP", "010")

‘ Get the GUID code for this value:

Dim strGUID As String

strGUID = MyOtherValue.GUID

COM interfaces



Introduction In the Baan OpenWorld Broker, to develop applications, you can create and configure objects in the repository browser. Only users with superuser status can open the repository browser. The Broker has a number of user-interface elements that you can use to set up a user interface for end users that use the Broker in an operational environment.

The most important types of user-interface elements are:

Drop-down menus. Windows and dialog boxes. The background of the main Broker window. Messages (for example, error messages).

For details, refer to the sections “Form,” “Menu,” and “Query” in Chapter 1 in the Reference Guide.

For information about user interfaces in multiple languages, refer to Chapter 12, “Language support.”

Drop-down menus Drop-down menus enable the user to start actions. To define drop-down menus, you must define menu objects. You can define menus for a particular user or a group of users. In this way, you can configure the user-interface for each user.

Windows and dialog boxes To create windows and dialog boxes, you must define several forms and queries:

A form defines the layout of the window. A form can contain data entry fields, buttons, pictures, and so on.

A query combines a form with data. A query can display the fields of a table row, a grid with table data, or simply numbers or text.

16 User interface

User interface


Forms Broker forms define the layout and the functionality of windows and dialog boxes. A form is always linked to a particular logical data type. The form can only display values of the type to which the form is linked.

Forms can contain tabbed pages. Forms can be configured to show at run-time only those controls that are appropriate to the current user. You can place standard elements such as a company logo on a base form. The other forms can inherit these elements from the base form. If the company logo changes, you must simply change the base form, and all the other forms will be changed automatically.

A form can contain:

Input fields. Used to control how data is displayed on the form and how the data can be edited.

Display fields. Display the result of an expression.

Push buttons. Used to enable the user to execute some action, for example, to switch to another form.

Static elements, such as text labels, pictures, and group boxes.

A form can also contain table viewers, multiline text fields, and even HTML fields, which enables you to display HTML pages.

Queries A query combines data of a certain type with a form to display the data. The query has an expression that determines the data that is displayed. The data can consist of table rows, but the data can also be simpler, for example, numbers, or text.

You can run a query as Multi Document Interface (MDI) window, or as a dialog box. The following section describes yet another way to use queries.

User interface


The main window You can place queries on the background of the Broker main window. These queries are called background queries. You can also place forms on the background. If a user has more than one background query, tabbed pages appear. The user can switch between background queries by clicking on the appropriate tab.

You can specify background queries in an environment object. The Broker will present these background queries automatically to all users linked to that environment.

You can use background queries in several ways, for example:

A particular user only uses a small number of data-entry windows. These windows can be configured as background queries in the environment object of that user.

You created an application that offers a number of functions to the end user. You can define a form with buttons that start these functions. This form can be placed in the background as the main menu of your application.

Messages Often, you want to place a message on the user’s screen, for example, an error message. To display this message, you can use the printf function in the scripting language.

printf statements in scripts do not appear if the script is evaluated on the server. Periodic processes, timed variables, and alerts, as well as the component integration subsystem’s scripts, are all evaluated on the server.

If you want more control over the appearance of the message, you can define a special form to display messages.

{

\forms\MessageForm . run ("Negative value not allowed.",8);

}

You can also send messages to the mailboxes of users. For more information, refer to “Sending messages to user” section in Chapter 9, “Messages.”

You can also use the msgBox operation of the System object to display a message box. For more information, refer to “System::msgBox” in the document Scripting Language Reference (U7278E US).

NOTE

EXAMPLE

User interface



This chapter provides a description of each type of user-definable objects. To create these objects, you can use the buttons in the object browser, or click New on the Objects menu. Also see the Baan OpenWorld Broker Reference Guide (U7461B US)

The following table lists the types of user-definable objects.

User-definable objects Object type Description Alerter An object that performs periodic boundary checks and

raises an alert if predefined conditions apply. Alerters are a special type of periodic processes.

Component An object in the repository that describes external applications, such as BaanFrontOffice or CODA-Financials.

Database connector

A connection to an Open Database Connectivity (ODBC) compliant data source. You can use this connection to directly manipulate databases by executing SQL statements.

DLL proxy A link between the Broker scripting language and a dynamic-link library (DLL) on your client computer or on the server.

Environment The environment controls the entire user interface, including the background queries and the menus that are visible.

File A mapping between an external data source and a logical data type. The file object serves as a variable, whose type is the associated table type. You can map to ODBC-compliant databases and to text files.

Form Broker forms are used to display information, to process data keyed in by users, and to display messages.

Global variable Global variables store values of a primitive type or a logical data type. You can change the value of the variable in expressions and scripts. The global variable is stored in the object repository and can be accessed from any client.

Iterator Iterators are used for fast bulk synchronization of data between a single originating component and multiple destination components.

17 User-definable objects

User-definable objects


Logical data type

Logical data types describe the nature and structure of data. This logical data description is independent of the physical form of the data being processed.

Mapper extension

Mapper extensions handle data access to enterprise applications. Mapper extensions can be used by logical data types and mapping objects.

Mapping object Mapping objects support the definition, and run-time execution of field mappings between two data types. Mapping objects are used in scripts.

Menu A definition of drop-down menus on the menu bar. You can define menus to customize the user interface of the Broker.

Message handler

Message handlers pick up messages of a particular type from a queue in the object repository and perform an operation on them, such as starting a workflow.

Message queue Message queue objects enable the Broker to buffer incoming messages until a message handler is free to deal with these messages.

Message source Message source objects define how to retrieve and handle incoming messages.

Message sink Message sinks allow you to send data as messages to outside applications through e-mail, message queues, and so on. These messages can consist of text strings or XML documents.

Object set An object set is an object that contains a list of other objects. You can use object sets to specify the collection of objects that must be exported to a file.

Periodic process A periodic process is an automatic process or task that can start at a predefined time and run from that point in time at predefined intervals.

Picture Picture objects store a graphics file into the object repository.

Profile A profile object stores a list of tasks to be executed in a fixed order. A profile may also include other profiles. In this way, you can create a multilevel structure.

Query A query object displays data of a certain type in a form designed for the purpose.

Resource Resource objects represent central resources of which there is a limited amount available, such as machines, people or other facilities. The workflow system uses resource objects to check if sufficient resources are available to execute a certain step.

Script A script object stores a piece of programming that can be invoked by task objects, form buttons, periodic processes, and so on.



Task A task object identifies an action that you specify by using the action wizard. Examples: Send an e-mail, Run a script, Start an iterator.

Text table Text table objects are used to store the texts that you display on forms, in messages, and so on. Text tables enable you to store a text in multiple languages and locales.

Timed variable A timed variable stores an expression and the last calculated value of that expression. The last calculated value is valid during a limited period. If the variable is queried about its value before the end of this period, the variable returns the last value, otherwise, the value is recalculated. You can use a timed variable to reduce the number of times that an expression must be evaluated.

User A user object must exist in the object repository for each person who must log on to the Broker.

User group A group of users with common characteristics. User groups facilitate flexible management of users.

Workflow Workflow objects are blueprints or templates for document routing.

Developer's Guide for BrokerPage 1

A Access rights, 11-2 Action wizard, 10-5 Alert, 1-8 Alerter, 1-8

B Background query, 16-3

C Check in, 13-1, 13-5 Check out, 13-1, 13-5 Code mapping, 8-21 Color scheme, 10-4 Color tool, 10-2 COM interfaces, 1-4, 15-1 Component integration subsystem, 8-1 Compressed object storage, 4-2 Configuration utility, 2-3 Construct, 8-14

D Delete, 8-14 Dependencies, 4-4

E E-mail, 9-4 Enumeration type, 6-1 Export locale strings, 12-2 Expression tool, 10-2 Expressions, 7-1

F Flags, 4-2 Fonts tool, 10-2 Form, 16-1, 16-2

G GetTimestamp, 8-14 GUID, 8-22

I Import locale strings, 12-2 Iterator, 8-24

K Kernel, 2-1

L Label, 13-6 Language support, 12-1 Load, 8-14 Locale strings, 12-1 Locking, 13-6 Log on, 11-2 Logging system, 14-1 Logical data type, 6-1, 8-6

M Mailbox, 9-5 Message class, 9-1 Message handler, 9-3 Message queue, 9-3 message sink, 17-2 Message source, 9-3

18 Index

Index

Developer's Guide for Broker Page 2

Messaging, 9-1 Microsoft Management Console, 2-3

N Named colors, 10-4 Naming rules, 4-1 NT service, 2-1

O Object flags, 4-2 Object relations, 4-4

P Periodic process, 1-7 PrepareStore, 8-14 Primitive operations, 8-14 Protected objects, 4-2

Q Query, 16-1, 16-2

R Repository browser, 3-1 Rollback, 8-13, 13-9

S Scripting language, 7-1 setFlags operation, 4-2 SMTP server, 9-4 Store, 8-14 StoreNew, 8-14 SYNC_ALWAYS_NEW, 8-10 SYNC_STORE_ALL, 8-10

T Time stamp, 8-10 Tool dock, 10-1 Translation support, 12-2 Trusted logon, 11-2 Two-phase commit, 8-11 Type, 6-1, 8-6 Type assistant, 10-7

U User, 17-3 User interface, 16-1 User management, 11-1

V Variable, 5-2 VBA. See Visual Basic for Applications VCS. See Version Control System VCS object, 13-4 Version Control System, 13-1

check in, 13-5 check out, 13-5 discard, 13-11 enable, 13-2 export, 13-10 get, 13-9 label, 13-6 locking, 13-6 rollback, 13-9

Visual Basic for Applications, 15-2

W Windows NT service, 2-1 Workflow, 17-3

developer's guide for broker - baansupport.combaansupport.com/docs/baan/developers guide for...

Documents