Baan_Ivc-Erp-Ln6.1-Migration-Flow
30 Thursday Aug 2012
Posted Baan Migration
in30 Thursday Aug 2012
Posted Baan Migration
in30 Thursday Aug 2012
Posted Baan Migration
in
30 Thursday Aug 2012
Posted Baan Migration
inExchange
This topic describes the most important differences between the Exchange (XCH) module in Baan IVc
and in ERP LN 6.1.
New and changed functionality
▪ Move to da package
In Baan IVc, the Exchange (XCH) module was part of the Baan IVc Utilities (tu) package.
In ERP LN 6.1, the module belongs to the Data Director package.
▪ Multi Site Control
The possibilties for exchanging data between multiple servers are extended: you can now use
the Multi Site Control feature to control the exchange of data between multiple sites. Refer to
Introduction to multisite control for details.
▪ Generation of audit settings
After creating an exchange scheme that is based on audit trail, you can generate the
corresponding audit settings through the Generate Audit Configuration (danch3225m000)
session. In Baan IVc the audit trail settings for the involved tables had to be set manually.
30 Thursday Aug 2012
Posted Baan Migration
inInstallation Wizard and Staging Wizard
This topic explains the concepts of the Installation Wizard and the Staging Wizard in ERP LN 6.1.
Installation procedure in Baan IVc
For Baan IVc different installation procedures are used for each Operating System / Database System
combination.
The installation procedures are described among others in the following documents:
▪ Installation Guide for Baan IVc4 on Microsoft SQL Server (U7210D US)
▪ Installation Guide for Baan IVc4 for Oracle on Windows (U7051I US)
▪ Installation Guide for Baan IVc4 for Informix on Unix (U7029E US)
▪ Installation Guide for Baan IVc4 for Informix on Windows (U7018L US)
▪ Installation Guide for Baan IVc4 for Oracle on Unix (U7028H US)
▪ Installation Guide for Baan IVc4 on Unix (U7016J US)
Installation Wizard and Staging Wizard in ERP LN 6.1
For ERP LN 6.1 the Installation Wizard is used to install the ERP LN software and its add-ons on any
Operating System.
The Installation Wizard is a generic installer for installing ERP LN 6.1 on the supported platforms.
The Installation Wizard always runs on a Microsoft Windows platform, which means that installation on
UNIX versions and IBM AS400 are carried out in client-server mode, while an installation on Microsoft
Windows is performed locally.
To support installation on UNIX and IBM AS400 in client-server mode, some APIs are made available
in the Baan Connection Service (BCS) of the Installation Wizard. To push the installable units to the
remote server, the Installation Wizard uses a File Transfer Protocol (FTP) connection. You can use the
Remote Executable Command (rexec) service to execute programs on the remote computer. Finally,
you can use the BW driver to start Enterprise Engine sessions on the remote computer.
The Staging Wizard is an application for loading installable units into the staging area. During this staging
process, the user can select the applications (installable units) from a medium that must be staged into
the staging area.
The Staging Wizard is available on the Enterprise Engine and ERP LN 6.1 Application media. After the
Installation Wizard is started from the CD-ROM, the administrator must type a destination path of the
staging area. Next, the staging wizard will show all the available installable units on the CD-ROM, and
the administrator must make a selection on which installable units must be staged. If the staging area
already exists, the staging wizard displays the version from the software components available in the
staging area, and the version from the CD-ROM. The administrator must make the decision on whether
the installable units in the staging area must be updated (or downgraded) with the installable unit on the
medium.
The Staging Wizard will not perform any dependency checking, which means that the administrator
must check which installable units and which versions must be staged into the staging area.
Example installable units:
▪ ES porting set
▪ Enterprise Server
▪ ERP LN
▪ License Manager
▪ Application Service Manager
▪ OpenWorldX Adapter for ERP LN
▪ ERP LN 6.1 DEM Models
▪ ERP LN 6.1 Demo Data
▪ ERP LN 6.1 LP – Chinese Traditional Pack
30 Thursday Aug 2012
Posted Baan Migration
inLicense Manager
This topic explains the concepts of Licensing in ERP LN 6.1.
License management and validation
A license management mechanism is a copy protection mechanism used to regulate the commercial
use of Infor software products. For testing and demonstration purposes, unprotected software is
dispatched with limited validity. The unprotected software must be validated before a specified expiration
date.
Licensing in Baan IVc
Licensing is part of the Baan IVc porting set. A short overview of licensing and validation in Baan IVc is
described below:
Validation procedure:
The license key request process for a Baan IVc software installation consists of the following steps:
▪ You start the validation process by requesting a license code. Upon your request you will
receive a License Code Information Report by email.
▪ Enter the license code in your application, along with other required information from the
License Code Information Report (number of Ascii and MS-Windows users).
▪ Make sure you have installed the Version Scan Tool.
▪ Generate the Security key and Requested System Configuration file using session ‘Print
Requested System Configuration’.
▪ The Version Scan Tool will start automatically. Complete the scan and save the output file.
▪ The validation key can be requested by uploading the Version Scan Tool output file.
▪ The received validation key can be entered in your system to activate the software.
Revalidation:
Revalidation of existing installations is required in case of the following events:
▪ Hardware changes ▪ Updates/changes in versions ▪ Hardware or operating system upgrades
▪ Changes between one database or another (e.g., Informix to Oracle) ▪ Increase in numbers of users
▪ Catastrophic failure of system requiring a complete reload
License Daemon and License Monitor:
To run the Baan IVc sessions, the License Daemon ($BSE/bin/licd6.1) must be up and running.
The License Monitor ($BSE/bin/licmon6.1) can be used to:
▪ Ping the license server (ping) ▪ Show server statistics (stats) ▪ Show user count (users) ▪ List users (who)
Licensing in ERP LN 6.1
Licensing is done by the License Manager.
The License Manager is the license manager for the majority of the Infor products. License Manager is
a central license manager in the sense that one license manager can provide licenses to a variety of
products. There is no need to install and configure a dedicated license manager per product.
To establish a licensing solution you need three components:
▪ The Infor application or product that adopts License Manager for licensing.
▪ The License Manager product for handling the licenses. It will check the license requests
from the adopting applications according to the information stored and validated with ERP.
▪ The Activation key that enables the license manager. The Activation key provides you with
a key in such a way that your adopting applications will work accordingly.
License Manager exists of three components:
▪ License Manager Server: The central component of License Manager is the server that
handles the requests for licenses, coming from adopting applications.
▪ License Manager MMC Snap-in: The configuration component is the graphical user-interface
working in Microsoft Management Console (MMC) to fully configure the server. This is called
the MMC Snap-in. The MMC Snap-in is the preferred way to configure BCLM servers, even
remote and even running in a non Microsoft Windows environment. There is also a traditional
Command Line interface available.
▪ License Manager Client: License Manager Client is an interface layer between adopting
applications and the central License Manager Server. The License Manager client provides
an API of invoking licensing functionality. All applications that use ERP licensing must have
the License Manager Client component installed.
License Manager license types:
The license deals can vary, but the license types remain the same. Therefore, License Manager does
not license according to a license deal, but according to license types.
Infor applications can be licensed in various ways, and to see how your application must be licensed,
you can refer to the Software License and Support Agreement (SLSA). Depending on the pricing strategy
of Infor , a restricted set of license types can be assigned to a specific application. For example, some
applications can be licensed through any license type, while others can only be licensed through a server
license only.
In general the license types are distinguished in node locking and user locking. With node locking the
adopting application can only work on a specific node in your network. A node can be a server, but also
a desktop. With user locking, the adopting application can only work with a specific named user or with
a limited amount of concurrent users.
License Manager validation procedure
The validation procedure consists of four main steps. The intention of the procedure is to activate the
installed products with an authorized activation key.
▪ Specify at the License Manager Server all the products that have been installed and that must
be licensed by means of License Manager. The result must be saved in a document. By
default, this document file is called License.xml.
▪ Upload this document to the Validation department. You can upload this document on the
Support Web site: http://www.support.baan.com
▪ Infor Validation checks the information in the license document against contract information.
If the license document is correct, Infor Validation generates an activation key. This key is
based on the data in the license document. To bypass the period, you must wait for the official
validated key. Infor can send you almost immediately a temporary activation key that activates
the applications for a limited period.
▪ Infor Validation sends the validation key back to the customer, who submits this activation key
to License Manager server. By doing so, all specified products in the license document become
activated. If other components are installed, or if additional licenses are bought, the license
document must be changed accordingly and a request for a new activation key must be carried
out following the described process.
30 Thursday Aug 2012
Posted Baan Migration
inOffice Integrations
This topic describes the differences between Microsoft Office Integrations in Baan IVc and in ERP LN
6.1.
Microsoft Office Integrations in Baan IVc
Baan IVc has no integration pack for Microsoft Office. However, you can create Microsoft Word and
Microsoft Excel devices. Through these devices, you can send reports to Word and to Excel.
The layout of the generated documents and workbooks is based on the ERP LN report layout. Possible
extra formatting (font types, pictures, etc.) must be done manually, after printing, in Word and Excel.
Microsoft Office Integrations in ERP LN 6.1
ERP LN 6.1 contains an integration pack that provides you the opportunity to integrate with Microsoft
Word and with Microsoft Excel: the “Integration Pack 2.0 for Baan ERP 5 and ERP LN 6 – Microsoft®
Office”
Through this integration pack you can:
▪ select records in a ERP session, and send them to Microsoft Word.
▪ select records in a ERP session, and send them to Microsoft Excel. Changes made in Excel
can be saved (uploaded) to ERP LN 6.1.
The structure and the layout (table fields, font types, pictures, etc.) for the Word documents and Excel
workbooks to be generated is defined in ERP related templates. Therefore, no additional formatting is
required after sending the data.
Refer to MS Office Integration for details.
Business Object Modeling
This topic describes the differences between the connectivity architecture in Baan IVc and in ERP LN
6.1.
Connectivity architecture in Baan IVc
The Baan IVc software is created from a database and user-interface perspective, rather than from a
business perspective.
In a lot of integrations, other applications connect, via OpenWorldX, to Baan IVc tables.
In such a connection the Baan IVc business logic, that completely resides in program scripts and DLLs,
is skipped. Therefore this business logic must be rebuilt in the BOIs that provide the connection.
Disadvantages of this connection architecture are:
▪ You need a lot of Baan IVc knowledge, e.g. about business logic and tables, to build BOIs.
▪ The BOIs do not work anymore when the Baan IVc business logic changes, e.g. through a
service pack.
This makes it hard to integrate Baan IVc with external applications.
Business Object Modeling in ERP LN 6.1
In ERP LN 6.1 the connectivity architecture has changed drastically. Some key characteristics are:
▪ Business Objects
The software is built from a business perspective: ERP LN 6.1 comes with various predefined
business objects that can be used to build integrations with external applications. When an
external application connects to a business object, automatically the relevant business logic
is executed via the DAL 2 scripts of the involved tables.
▪ Business Object structure
Each business object consists of 2 layers:
▪ a public layer: this layer forms the connection with the outside world. This layer consists
of public attributes, methods, and method arguments. External applications can activate
the public methods via OpenWorldX to run an action, e.g. create or update a Sales Order,
in ERP LN 6.1. The method arguments are in XML tree format.
▪ a protected layer: this is an internal layer that external applications cannot access. It forms
the mapping between the protected layer and the Baan application. This layer consists of
tables, protected attributes (mapping to table fields), protected methods and method
arguments.
A business object can consist of multiple components, each having their own protected layer.
For example: the Calendar business object consists of a Header and a WorkingTime
component. There is only one public layer for the entire business object.
▪ Business Object modeling
Business Objects are maintained via the Business Objects (ttadv7500m000) session and are
stored in the BOR. After a conversion to runtime, a business object DLL is generated in the
BOL. Refer to To Model a Business Object for details.
▪ Execution of business logic
To run an action in ERP LN 6.1, an external application can invoke (via OpenWorldX + BOIs)
a method in a business object DLL in the BOL. For example, the Create method in the
SalesOrder DLL. The business logic in the DAL2 scripts of the involved tables is executed
automatically. So, there is no need to rebuild session logic in the integration BOIs!
▪ User friendliness in dealing with connectivity
Baan will not change business objects in such a way that existing integrations with external
packages do not work anymore: Baan will only add components, never change or delete
components.
The new connectivity architecture makes integrations to external applications easier and more flexible:
▪ You don’t have to rebuild session logic in the integration BOIs. So, to build an integration you
don’t need to know the ERP LN 6.1 tables and business logic. You only need to know the
structure of the business objects.
▪ After a change in the ERP LN 6.1 business logic, the integration BOIs still work. So, you don’t
have to modify these BOIs.
The Business Object Modeling sessions
In ERP LN 6.1 you can use the following sessions to maintain and test business objects:
▪ Business Objects (ttadv7500m000) ▪ Convert BOR to Runtime (tlbct1210m000) ▪ BOL Test Tool – Public Layer (tlbct3250m000)
▪ BOL Test Tool – Protected Layer (tlbct2210m000) ▪ Test History (tlbct3550m000)
30 Thursday Aug 2012
Posted Baan Migration
inIntegration Tools
Changed functionality
Exchange
This topic explains the differences between the Exchange module in Baan IVc and the Exchange module
in ERP LN 6.1.
Exchange in Baan IVc
In Baan IVc:
▪ The Exchange module (xch) is located in the Utilities (tu) package.
▪ The log files do not contain many details. For example, in case of a database error, only the
error code is recorded.
▪ You can generate exchange schemes via the Generate Exchange Scheme (tuxch0251m000)
session.
▪ In regular export and import procedures, the ASCII files are stored in a separate directory for
each run number. The run number is not available to the outside world. Therefore external
applications do not know what directory the files must be written to or read from. To solve this
problem, you need to program a session or script to copy the files before each regular import
or after each regular export.
Exchange in ERP LN 6.1
▪ Module location
The Exchange module is moved from the Utilities (tu) package, to the Data Director (da)
package. All session codes for ERP LN 6.1 start with the da package code.
▪ Improved logging
The log files contain more details: the descriptions of database errors (including the table fields
involved) and exchange error messages are logged. More details are logged for incorrect
records.
▪ Compression of ASCII Files
It is now possible to use compressed ASCII files during regular export and regular import
actions.
▪ In the Export Data (on a Regular Basis) (daxch0234m000) session, you can indicate
whether the ASCII files must be compressed after they are exported.
▪ In the Import Data (on a Regular Basis) (daxch0224m000), you can indicate whether the
compressed ASCII files must be restored to their original format before the import
procedure.
▪ Generation of exchange schemes
The procedure to generate an exchange scheme has changed. To generate an exchange
scheme, you must use the Create ASCII File Fields and Relations (daxch0203m000) session,
which can be started from the Exchange Schemes (daxch0501m000) session. Refer to To
generate exchange schemes for detailed information.
▪ Multi Site Control (since ERP 5.0)
In Exchange, you can now use Multi Site Control functionality to set up a batch-driven replication
server. This enables you to maintain the same data at multiple sites.
Some key features are:
▪ Each site owns its data and processes and, in turn, each site decides when and how often
to run exchange batches.
▪ A target site can subscribe to data that is made available at a source site. In this way,
source and target sites can automatically be synchronized.
▪ If one site is not available for some time, or if the batches at several sites do not run
synchronously, Exchange ensures that no data will be missing.
▪ Multisite Control enables you to not only use one-to-one topologies, but also one-to-many,
many-to-one, or many-to-many.
For details refer to Introduction to multisite control.
▪ Advanced file handling
In the Exchange Schemes (daxch0101s000) session, you can specify common directories
from where, or towards which, ASCII files are copied automatically in regular import and regular
export procedures. This makes it easier to integrate ERP LN 6.1 with external applications,
because you don’t need to program a separate session or script to copy the files. Refer to
Advanced file handling using common directories for details.
▪ In the Exchange Schemes (daxch0101s000) session, you can define an owner for an exchange
scheme. The owner is displayed in the Exchange Schemes (daxch0501m000) overview
session, and enables you to group and sort exchange schemes in the same Baan company.
▪ Default numbering
When you enter new ASCII file fields and table and field relations, ERP LN 6.1 automatically
increases the corresponding sequence numbers with 10.
Default numbering is implemented in the following sessions: ▪ ASCII File Fields (daxch0103s000) ▪ Table Relations (Import) (daxch0121s000) ▪ Table Relations (Export) (daxch0131s000) ▪ Field Relations (Import) (daxch0122s000) ▪ Field Relations (Export) (daxch0132s000)
▪ Import using DAL
In the Table Relations (Import) (daxch0121s000) session you can specify whether the import
process uses the Data Access Layer (DAL). If you use the DAL, Exchange carries out all the
constraint checks, integrity checks and side effects, such as updates on other tables, that are
programmed in the DAL. Database integrity is guaranteed automatically. Refer to Import using
the Data Access Layer (DAL) for details. Refer to DAL 1 and DAL 2 for details on DAL scripts.
▪ Generation of audit configuration
If you create an exchange scheme that is based on audit trail, you can generate the audit
settings for the tables involved, rather than defining the audit settings manually. To generate
the audit settings, use the Generate Audit Configuration (daxch1201m000) session. Refer to
To use audits in the exchange module for details.
▪ Terminology changes
Some terms used in Exchange have changed. The titles of the sessions involved are changed
correspondingly:
▪ “ASCII File Formats” is changed into “ASCII File Fields”
▪ “Relation” is changed into “Conversion table”
▪ “Import Script” is changed into “Import Program”
▪ “Export Script” is changed into “Export Program”
▪ Exchange Scheme Delivery
In some cases, exchange schemes for specific integrations are created by Baan Development.
Such schemes are delivered as additional XML files. Refer to Exchange Scheme Delivery for
ERP for details.
30 Thursday Aug 2012
Posted Baan Migration
inData Access Layer (DAL & DAL2)
This topic explains the differences between database integrity and business logic handling in Baan IVc
and in ERP LN 6.1.
Database integrity and business logic in Baan IVc
The business logic of Baan IVc completely resides in program scripts and DLLs. The program script of
a session contains both, user interface logic and database logic:
▪ The user interface logic is used to change the default behavior of the session. A program
script can contain various sections that are used to enable or disable fields, define default
values for fields, calculate the values for fields, and so on.
▪ The database logic in the program script ensures the logical integrity of the database. This
logic usually resides in:
▪ multiple “check.input” field sections that are used to check the input values for the fields
in a session. These “check.input” sections contain logical integrity rules, for example: “the
net weight can not be greater than the gross weight” and “the Expiry date should be later
than or equal to the Quotation date”.
▪ a “main.table.io” section that is used to program actions that must be executed when read
or write actions occur on the main table. For example: after saving a new order line, the
“Stock on Order” field in the Items table must be updated automatically.
This architecture has the following disadvantages:
▪ Redundancy of database logic. If multiple sessions operate on the same main table, the same
database logic, e.g. input checks, is stored in multiple program scripts.
▪ Hard to use for integrations. Via OpenWorldX, other applications can connect to Baan tables:
in such a connection, the business logic in the program scripts is skipped. Therefore this logic
must be rebuilt in the BOIs that provide the connection. If the business logic in Baan IVc is
changed, the corresponding BOIs must be adapted as well.
Data Access Layer (DAL & DAL2) in ERP LN 6.1
The following changes are implemented in ERP LN 6.1:
▪ Data Access Layer (DAL)
The database logic in the “check.input” and “main.table.io” sections is removed from the
program scripts and is now stored in Data Access Layer (DAL) scripts. The DAL scripts ensure
the logical integrity of the database.
▪ Elimination of redundancy
Each DAL script belongs to a single table definition. The name of the DAL script is identical
to the table name, for example “tccom001”, or “tdpur100”. This architecture eliminates the
redundancy of database logic. All database logic for a particular table is centralized in a single
DAL script, rather than being spread across multiple program scripts. All sessions that operate
on a table use the same database logic, that is defined in the table’s DAL script.
▪ DAL hooks
A DAL usually consists of multiple hooks. A hook is a function, with a predefined name, that
is used to program logical integrity rules for database access. A DAL can contain multiple
types of hooks that can, for example, contain integrity rules for various table fields and can
automatically run actions when read or write actions occur on the main table.
▪ User Interface (UI) script
The database logic in the “check.input” and “main.table.io” sections is removed from the
program scripts and these sections are replaced by DAL hooks. Most of the logic that remains
in the program scripts, is related to the user interface. Therefore, the program scripts are now
called User Interface (UI) scripts.
In ERP LN 6.1, two types of Data Access Layer scripts exist: DAL 1 and DAL 2. Refer to DAL 1 Overview
and DAL 2 Overview for details on these types.
30 Thursday Aug 2012
Posted Baan Migration
inSoftware Configuration Management (SCM)
This topic explains the concepts of Software Configuration Management (SCM) in ERP LN 6.1 and
compares this to the version control features in Baan IVc.
Version control of software components in Baan IVc
Baan IVc does not offer a real version control system for software components:
▪ a single package VRC can only contain one version of each software component. It is not
possible to store multiple revisions of the same component. Program scripts form an exception
to this: each program script may have a maximum of five variants in the same VRC.
▪ Components are only locked during the time they are being edited. You can not lock a
component for a longer period. So, during your absence, other developers might (accidentally)
perform changes in your component.
Software Configuration Management (SCM) in ERP LN 6.1
Software Configuration Management (SCM) is a version control system for all software components
developed in ERP LN 6.1 Tools.
SCM is especially useful if multiple developers create and maintain software components in the same
VRCs.
SCM offers the following features:
▪ Check-out
You can check out a software component from an original VRC to a development VRC. When
the component is checked out, you are the only one that can modify and test the component.
Each time you perform a check-out action, a new revision of the software component is created
in the development VRC.
▪ Check-in
If the changes on the software component are tested and completed, you must check in the
component, to make the changes available to other users.
▪ Undo check-out
If necessary, a check-out action can be reversed through the undo check-out procedure.
▪ Revisions
A development VRC usually contains multiple revisions for the same software component.
You can maintain these revisions through the Component Revisions (ttscm1501m000) session.
If necessary, you can restore an older revision.
The Software Configuration Management (SCM) sessions
In ERP LN 6.1 the following Software Configuration Management (SCM) sessions can be used:
▪ (De)activate SCM and Component Management by Package VRC (ttscm0501m000)
▪ Activate SCM and Component Management by Package VRC (ttscm0110s000)
▪ Global Check-In of Components (ttscm1200m000)
▪ Global Undo Check-Out of Components (ttscm1202m000) ▪ Component Revisions (ttscm1501m000)
▪ Print Component Revisions (ttscm1401m000) ▪ Delete Component Revisions (ttscm1201m000)
Dynamic sessions and dynamic forms (DFE)
This topic explains the concepts of Dynamic sessions and dynamic forms (DFE) in ERP LN 6.1 and
compares this to the static forms in Baan IVc.
Sessions and forms in Baan IVc
In Baan IVc:
▪ All sessions and forms are static, i.e. the forms have a fixed layout: the labels and fields in a
form are always displayed on the same position.
▪ Forms are edited through an ASCII oriented form editor (ottadvformedit).
▪ Sessions and forms are both generated through the Generate Sessions (ttadv2290m000)
session.
▪ Forms are linked to sessions, but are edited separately.
▪ Multiple forms can be linked to a single session. At runtime, these forms are displayed as
parallel form tabs.
▪ Separate sessions are used to display and maintain records. For example a multi-occurrence
overview session is used to display Item data and a single occurrence details session is used
to maintain Item data.
Dynamic sessions and dynamic forms in ERP LN 6.1
The following list is a summary of the changes that are implemented in ERP LN 6.1:
▪ The form layout is dynamic: the position of fields and labels is not fixed, but can differ per
situation.
▪ Forms are edited through the Dynamic Form Editor (DFE).
▪ You can create sessions through the Sessions (ttadv2500m000) session and the Dynamic
Form Editor (DFE).
▪ Each session has only one form.
▪ Various sessions are used as both an overview session and a details session. ▪ You can implement Dynamic Index Switching.
▪ Text fields can be displayed as text boxes, where you can type the text directly.
▪ You can change the appearance of string fields and enum fields, e.g. from a drop down list
box to a set of radio buttons.
▪ You can define multiple form commands for each session/form.
Refer to Dynamic sessions and dynamic forms for details.
30 Thursday Aug 2012
Posted Baan Migration
inText Management
This topic explains how text management and various text related sessions in Baan IVc Tools were
changed in ERP LN 6.1.
Text Management in Baan IVc
In Baan IVc:
▪ Texts are edited through the Baan Text Editor (tttxt2200m000) or through Notepad.
▪ Text group authorizations and default text groups are defined for each individual user.
▪ The texts and all related settings, such as text windows, text groups, text group authorizations
and default text groups, are stored per company number.
Text Management in ERP LN 6.1
In ERP LN 6.1 the following changes are implemented:
▪ Text editing
Multiple text editors are available. The text editor, that is started when you edit a text, depends
on the text group to which the text belongs.
You can select one of the following editors:
▪ BAAN Editor: the standard Baan text editor. Identical to the text editor in Baan IVc.
▪ Multi-line: a new Baan text editor. This editor is similar to Notepad. However, it runs on
the Baan Server, not on the client PC. ▪ Word ▪ Word without RTF
Refer to the online help of the Text Groups (tttxt1110m000) session for more information on
these editors.
▪ Authorizations and defaults
The settings for text group authorizations and default text groups are group based rather than
user based: these settings are defined in templates. Each template can be linked to multiple
users. Refer to User Management (p. 249) for more details on templates and users.
The following sessions are used to define the authorizations and defaults:
▪ Text Group Authorization Template (ttams1122m000) ▪ Default Text Groups Template (ttams1121m000)
▪ Default Text Groups by Text Field Template (ttams1120m000)
▪ Storage
Texts, text windows and text groups are stored per company. However, the templates that
contain the settings for text group authorizations and default text groups are stored in company
000. If Word is used as a text editor, the format settings (RTF settings) are stored separately
in the RTF texts (tttxt015) table.
▪ Text overview session
The Texts Overview (tttxt1500m000) session is used to display a list of texts for a specific
language and text group range. Through the Specific menu you can start various other
sessions, for example the Find and Print Patterns in Texts (tttxt1430m000) session.
▪ Text boxes
In ERP LN 6.1 sessions and forms are dynamic. In dynamic forms text fields can be displayed
as text boxes, where you can type the text directly. However, in most sessions the text handling
is similar to the situation in Baan IVc: the form contains a check box, indicating whether a text
exists for a record, and the text is edited through a text editor. Refer to Dynamic sessions and
dynamic forms (DFE) (p. 258) for more details on dynamic sessions and dynamic forms.
The Text Management sessions
Refer to The Text Management sessions for information on the sessions that can be started from the
Text Management menu.
Audit Management
This topic explains the differences between Audit Management in Baan IVc and in ERP LN 6.1.
Audit Management in Baan IVc
In Baan IVc:
▪ Tables that must be audited are linked to a database definition, for which audit trail is active.
All remaining tables are linked to another database definition for which audit trail is not active.
The Assign Tables to Databases (ttaad4111m000) session is used to link each table to the
desired database definition.
▪ Audit trail is mandatory for various parameter tables. The Load Mandatory Tables for Audit
(ttaad4211s000) session is used to link these tables to the “audit” database definition.
▪ You can activate audit trail for tables, not for individual table fields. When a user inserts,
updates or deletes a record in an audited table, only the content of the key fields and changed
fields is stored in the audit file.
▪ Some audit settings can only be defined by editing runtime files directly in the operating system,
for example:
▪ You must edit the audit_spec file to define security settings, the maximum audit trail file
size, and the maximum number of audit trail files.
▪ To specify an audit host for the audit server, you must edit the tabledef6.1 file.
▪ Security level and maximum file size can be defined, per audit sequence, through the Maintain
Audit Information File (ttaad4160m000) session.
▪ The directories where the audit trail files are stored, are defined in the Maintain Audit File
Directories (ttaad4116m000) session.
Audit Management in ERP LN 6.1
In ERP LN 6.1 the following changes are implemented:
▪ Audit configuration
The configuration of audit settings is centered around audit profiles. To define audit settings
you must create one or more audit profiles. In an audit profile you can group the tables that
must be audited. Each audit profile is linked to a company group, which determines for which
companies the specified tables will be audited. Audit profiles can be grouped in audit categories
to bundle profiles in the same functional area.
This way all settings that serve a specific purpose can be grouped. For example:
▪ all settings for auditing changes in parameters, or
▪ all settings for auditing fields that affect a particular exchange scheme, or
Note: audit configurations for a specific exchange scheme can be generated through the
following sessions respectively: Generate Audit Configuration (daxch1201m000) and Generate
Audit Configuration (danch3225m000).
▪ Audit settings for parameter tables
Most packages contain parameter tables for which audit trail is mandatory. For each of these
packages, ERP LN 6.1 contains a predefined audit profile that contains the audit settings for
the relevant parameter tables. For example: the “tc standard” profile contains the audit settings
for the parameter tables in the Common package.
▪ Audit settings on table field level
For each table in an audit profile you can ▪ activate audit trail for all fields, or
▪ activate audit trail for only a subset of the fields in the table: you must specify the fields
for which audit trail must be activated, and per field you must select the desired audit type.
▪ No manual editing of runtime files
Operating system files, such as audit_cols, audit_hosts, audit_spec and auditdef6.2, are used
to store audit configuration settings. However, you should not edit these files via the operating
system. The audit configuration is entirely specified using sessions. To update the
corresponding operating system files, you must run the Create Runtime Audit Definitions
(ttaud3200s000) session. This session can be started via the Specific menu in most audit
configuration sessions. For example: to define an audit host for the audit server, you must run
the Audit Hosts (ttaud3130m000) session and, after defining the host, create the runtime audit
definitions.
▪ Security level and file size
The security levels and maximum file sizes for audit sequence files are defined in the following
sessions respectively: ▪ Audit Trail Security (ttaud3137m000) ▪ Audit Trail File Sizes (ttaud3135m000)
▪ Audit file directories
The location, in the operating system, for audit files is specified in the Audit Trail Paths
(ttaud3136m000) session.
▪ New module
Most audit configuration sessions are entirely new. They belong to the new Audit Management
(tt/aud) module.
▪ (De)activation of audit configuration entities
Audit profiles can be activated and deactivated. This enables you to easily switch between
different audit settings: you can, for example, simply deactivate an audit profile, activate another
audit profile and convert the new settings to runtime.
▪ Export/Import of Audit profiles
To enable a quick audit configuration, audit profiles can be exported and imported through
the following sessions: ▪ Export Audit Profiles (ttaud3201s000) ▪ Import Audit Profiles (ttaud3202s000)
▪ Import Audit Profile from Additional File (ttaud3203s000)
▪ Transaction notifications
You can define a replication process that transfers changes, based on the content of audit
files, to another system. ERP LN 6.1 uses transaction notifications to ensure that only committed
transactions are replicated. For details, refer to the online help of the Transaction Notifications
(ttaud1510m000) session.
Application Development
This topic explains the differences between the Application Development concepts in Baan IVc and ERP
LN 6.1.
Application Development in Baan IVc
In Baan IVc:
▪ An ASCII oriented menu editor is used to modify the lay-out of the menus. A menu lay-out
usually consists of labels, menu fields, special fields, and a choice field. The menu_layout is
only used in the Baan ASCII (ba) user interface.
▪ All sessions and forms are static, i.e. the forms have a fixed layout and are edited through an
ASCII oriented form editor (ottadvformedit).
▪ For each language, a separate set of menu dumps, form dumps and report objects is stored.
▪ The program script of a session contains the entire application logic of the session: the session’s
user interface logic as well as the session’s database logic.
Application Development in ERP LN 6.1
The following changes are implemented in ERP LN 6.1
▪ ERP LN 6.1 does not have an ASCII interface. Therefore the menu-layout (field positions,
choice field, etc.) is not relevant anymore. To edit the contents of a menu, such as sessions
and sub menus, you must use the Menu Fields (ttadv3561m000) session.
▪ All sessions and forms are dynamic, i.e. the layout of a form is not fixed. The runtime
appearance of a dynamic form is based on the order and grouping of fields that is defined in
the form definition and on the table field authorizations of the user. Dynamic forms are edited
through the Dynamic Form Editor. Refer to Dynamic sessions and dynamic forms (DFE) (p. 258)
for more information.
▪ There is only one set of dumps/objects of forms, menus and reports for all languages. Labels
are compiled separately. Software translation is much easier now. Refer to Language
Translation Support (LTS) (p. 259) for more information.
▪ A program script only contains the session’s user interface logic. The database logic, e.g. the
execution of data integrity checks and of non-interactive update actions, is now stored in a
Data Access Layer (DAL) script. Refer to Data Access Layer (DAL & DAL2) (p. 261) for more
information.
Further, the following new application development concepts are introduced in ERP LN 6.1:
▪ Software Configuration Management (SCM) (p. 257) ▪ Multi Main Table (MMT) sessions (p. 260)
The Application Development sessions
Refer to the concepts mentioned above for a list of relevant sessions per topic.