Integration framework for SAP Business One

Entities to be used in Flow Design Variables, Properties & Co.

Author: Heinz Pauly Last Modified: June 21, 2011

Table of Contents
1. General................................................................................................................................................ 2 2. Overview Table.................................................................................................................................... 5 3. Variables ............................................................................................................................................. 6 4. In-Memory Variables ........................................................................................................................... 9 5. Message Values ................................................................................................................................. 11 6. SLD Properties ................................................................................................................................... 13 7. Config Properties ............................................................................................................................... 15 8. Global Properties ............................................................................................................................... 17 9. Global Tables ..................................................................................................................................... 20 Copyrights, Trademarks, and Disclaimers............................................................................................... 25

1. General
System Variables Local Variables Global Variables Variables Memory Variables In-Memory Variables Session Variables Message Values Element Values SLD Properties Config Properties Global Properties Properties Global Tables

Usage in parameter fields of an Atom UI $name $string(name) Placeholder for the value of a System Variable, Local Variable, Global Variable or Global Property. Placeholder for the value of a Local Variable, Global Variable or Global Property. Explicit type casting to string to bypass the cross-side scripting check for a sql call. Only relevant in the context of a sql call atom. Placeholder for the value of the first element with this name in the current B1if message. Placeholder for the value of the first element with this name in the section, produced by the atomx in the current B1if message. Placeholder for the value of a Memory Variable. Placeholder for the value of a Session Variable Placeholder for the value of a property related to an entry in the SLD (e.g. $*0010000101.JDBC.url*) Placeholder for the value of a Global Table Type 1. row can be a number (e.g. 2) or a condition (e.g. 2=233 or 2=233) Placeholder for the value of a Global Table Type 2 row can be a number (e.g. 2) or a condition (e.g. 2=233 or 2=233) Placeholder for the value of a B1if connectivity or runtime parameter

$[name] $[atomx/name] $(name) $((name)) $*sysid.adapter.prop* ${tbl[row,col]} ${tbl[row,row,col]} $?cfgpar?

For all bracketed notations, you can use a Local or Global Variable inside the notation to specify the values (name, atomx, tbl, row, col). Sample: $(($name))

Inbuilt System Variables $msg $now $today $userid $username Variable addressing the root tag of the message, sent by the sender system Current time in format HH:MM:SS Current date in format YY-MM-DD) Identifier of the logged in user (session based scenarios only) Name of the logged in user (session based scenarios only)

Inbuilt Config Properties (Connectivity and Runtime Parameter) $?Runtime.B1i HTTP Port? $?Runtime.B1i HTTPS Port? $?Runtime.B1i Server? $?Connectivity.Internet: Proxy Host? $?Connectivity.Internet: Proxy Port? $?Connectivity.Send Email: SMTP Server? $?Connectivity.Send Email: SMTP Port? $?Connectivity.Send Email: SMTP User? $?Connectivity.Send Email: SMTP Password? Inbuilt SLD Properties (SAP Business One) $*xxxxxxxxxx.B1DI.b1Server* $*xxxxxxxxxx.B1DI.licenseServer* $*xxxxxxxxxx.B1DI.company* $*xxxxxxxxxx.B1DI.dbType* $*xxxxxxxxxx.B1DI.dbUser* $*xxxxxxxxxx.B1DI.userName* $*xxxxxxxxxx.B1DI.password* $*xxxxxxxxxx.B1DI.language* $*xxxxxxxxxx.B1DI.isTrust* $*xxxxxxxxxx.B1DI.jcoPath* $*xxxxxxxxxx.B1DI.diProxyHost* $*xxxxxxxxxx.B1DI.diProxyPort* $*xxxxxxxxxx.B1DI.proxyHost* $*xxxxxxxxxx.B1DI.proxyPort* Inbuilt SLD Properties (File System) $*xxxxxxxxxx.FILI.filePattern* $*xxxxxxxxxx.FILI.Encoding* $*xxxxxxxxxx.FILI.Delimiter* $*xxxxxxxxxx.FILI.WrapChar* $*xxxxxxxxxx.FILI.PayloadType* $*xxxxxxxxxx.FILO.filePattern* Inbuilt SLD Properties (Database) $*xxxxxxxxxx.JDBC.driver* $*xxxxxxxxxx.JDBC.url* $*xxxxxxxxxx.JDBC.username* $*xxxxxxxxxx.JDBC.password*

Inbuilt SLD Properties (HTTP) $*xxxxxxxxxx.HTTA.destProtocol* $*xxxxxxxxxx.HTTA.destHost* $*xxxxxxxxxx.HTTA.destPort* $*xxxxxxxxxx.HTTA.destPath* $*xxxxxxxxxx.HTTA.query* $*xxxxxxxxxx.HTTA.proxyHost* $*xxxxxxxxxx.HTTA.proxyPort* $*xxxxxxxxxx.HTTA.method* $*xxxxxxxxxx.HTTA.authentication* $*xxxxxxxxxx.HTTA.user* $*xxxxxxxxxx.HTTA.password* $*xxxxxxxxxx.HTTA.user2query* $*xxxxxxxxxx.HTTA.password2query* $*xxxxxxxxxx.HTTA.sslTrustStorePath* $*xxxxxxxxxx.HTTA.sslTrustStorePassword* $*xxxxxxxxxx.HTTP.associatedSrvIP* Inbuilt SLD Properties (R/3) $*xxxxxxxxxx.RFCA.applicationSever* $*xxxxxxxxxx.RFCA.user* $*xxxxxxxxxx.RFCA.language* $*xxxxxxxxxx.RFCA.maxConnections* $*xxxxxxxxxx.RFCA.gatewayHost* $*xxxxxxxxxx.RFCA.senderPort* $*xxxxxxxxxx.RFCA.receiverPort* $*xxxxxxxxxx.RFCP.applicationSever* $*xxxxxxxxxx.RFCP.user* $*xxxxxxxxxx.RFCP.language* $*xxxxxxxxxx.RFCP.maxConnections* $*xxxxxxxxxx.RFCP.gatewayHost* $*xxxxxxxxxx.RFCP.unicode*

$*xxxxxxxxxx.RFCA.client* $*xxxxxxxxxx.RFCA.password* $*xxxxxxxxxx.RFCA.systemNumber* $*xxxxxxxxxx.RFCA.gatewayServiceNumber* $*xxxxxxxxxx.RFCA.senderPartner* $*xxxxxxxxxx.RFCA.receiverPartner* $*xxxxxxxxxx.RFCP.client* $*xxxxxxxxxx.RFCP.password* $*xxxxxxxxxx.RFCP.systemNumber* $*xxxxxxxxxx.RFCP.gatewayServiceNumber* $*xxxxxxxxxx.RFCP.programID*

Inbuilt SLD Properties (Web Services) $*xxxxxxxxxx.WSAN.destProtocol* $*xxxxxxxxxx.WSAN.destHost* $*xxxxxxxxxx.WSAN.destPort* $*xxxxxxxxxx.WSAN.destPath* $*xxxxxxxxxx.WSAN.query* $*xxxxxxxxxx.WSAN.proxyHost* $*xxxxxxxxxx.WSAN.proxyPort* $*xxxxxxxxxx.WSAN.authentication* $*xxxxxxxxxx.WSAN.user* $*xxxxxxxxxx.WSAN.sslTrustStorePassword* $*xxxxxxxxxx.WSAN.password* $*xxxxxxxxxx.WSAN.sslTrustStorePath* $*xxxxxxxxxx.WSAR.associatedSrvIP* $*xxxxxxxxxx.WSAS.destProtocol* $*xxxxxxxxxx.WSAS.destHost* $*xxxxxxxxxx.WSAS.destPort* $*xxxxxxxxxx.WSAS.destPath* $*xxxxxxxxxx.WSAS.query* $*xxxxxxxxxx.WSAS.proxyHost* $*xxxxxxxxxx.WSAS.proxyPort* $*xxxxxxxxxx.WSAS.authentication* $*xxxxxxxxxx.WSAS.user* $*xxxxxxxxxx.WSAS.sslTrustStorePassword* $*xxxxxxxxxx.WSAS.password* $*xxxxxxxxxx.WSAS.sslTrustStorePath*

2. Overview Table
Definition System Variables Local Variables pre defined by B1if Assign Values internal during processing Scope Everywhere Usage Atom UIs

Global Variables

Scenarios-Step Design Processing -[VLocal] Atom UI [VarL] fix by design or Scenario Step Scenarios-Step dynamically Design Scenariosbased on Package Design - Processing All Scenario Steps of inbound Definitions [VGlobal] Atom UI [VarG] message Scenario Package

inside the XSL coding <xsl:variable name="mem1" select="document('/com.sap.b1i.internal.xc/xml/ Memory Variables ipobag.xml?mem1=ABC')"/>

Scenario Step

Session Variables Message Values

Global Properties

Existent with the first incoming HTTP call of a Scenario Package, accessible for all Scenario inside the XSL coding (authentication and/or processing flow) Steps, triggered by <xsl:variable name="mem1" synchronous HTTP. select="document('/com.sap.b1i.internal.xc/xml/ programatically Expires with the sessioninfo.xml?sess1=ABC')"/> during flow session expiration tags to be placed inside the XSL coding processing Scenario Step default by design or customized based on Scenarioscustomer Package DesignScenarios-Step DesignAll Scenario Steps of definition Definitions Processing-[Prop] during setup Scenario Package

SLD Properties

pre-defined in B1if

SLD maintenance screen

Config Properties

Maintenance-Cfg Runtime and Maintenance-Cfg Connectivity

Global Tables

Scenarios-Package Design-Definitions

customer definition customer definition during setup

Access inside the xsl coding or in the Atom Everywhere UIs to specify the All Scenario Steps of atom Scenario Package parameters

3. Variables
There are three different types of variables available in B1if. System Variables Local Variables Global Variables Definition The System Variables are predefined. The following System Variables are available: $msg - a variable addressing the root tag of the message, sent by the sender system $now - current time in format HH:MM:SS $today - current date in format YY-MM-DD) In addition the following System Variables are available to access user information. These are relevant for session based login via HTTP only and only accessible during runtime and not in the test environment. The values are depending on the settings inside the authentication processing. $userid identifier of the logged in user $username name of the logged in user The Local Variable you define with B1if Scenarios Step Design Processing VLocal or directly in the atom screen by clicking the button [VarL]. The Global Variable you define with B1if Scenarios Package Design Definitions, via Scenarios Step Design Processing VGlobal or directly in the atom screen by clicking the button [VarG]. You can add and delete Local / Global Variables and you can maintain the values. These values can be explicit values (literals) and xPath expressions. The values of the Variables will be set during runtime before your processing flow is triggered. Therefore the xPath statement can access all data in the B1if message which is available at that point of time.

To define a literal you can just start the value with the hash (#) character (gvar1) or you wrap it with the apostrophe () character (gvar3). In case the value is a number (e.g. 1234), you can just type it in without hash or wrapped by the apostrophe. In this case this string is interpreted as number. With the value 1234 this is not a problem, but please consider that leading zeros will be deleted automatically (gvar4 will end in the value 1). You can also use xpath expressions which will be automatically processed. Just type in the value like in the example gvar8. You can also use the System Variable $msg to address the root tag of the message, sent by the sender system (gvar7). Another option to use the xpath functions, like number(), string (), or even combine (gvar5, gvar9) or calculate new values (gvar6) by referring to other variables. The example above will end in following values: gvar1 gvar2 gvar3 gvar4 gvar5 gvar6 gvar7 gvar8 gvar9 any text 001 001 1 0010011 3 true myobject truemyobject0010011

Scope System Variables are always existent. Global Variables are existent for all Scenario Steps of a particular Scenario Package. Local Variables are existent for the particular Scenario Step in which they are defined. In case a Variable is defined as local and as global, the local one will win. All Variables can be used during the complete process flow. Local and Global Variables are available in the header of the B1if message.
<Msg ... > <Header> ... <Variables> <var id="mystring" value="value"/> ...

By default the Local and Global Variables will be generated into the xsl stylesheet of a transformation atom which allows you to access them directly from your xsl coding. Optional you can de-activate the generation via Maintenance Cfg Dev Environment Generate Variables to XSL).

Assignment of Values Variables are assigned with the concrete values during runtime directly before your process flow is triggered. The values for the System Variables are set at the beginning of the transaction internally based on system timestamp resp. based on settings in the authentication. The values for the Local Variables and Global Variables are assigned fix via literals during the design time or dynamically during runtime based on the incoming message.

Usage inside the Processing Flow You can use the Local and Global Variables in your XSL coding. All Variables you can also use in the atom UIs inside the parameter definition. All parameters supporting the variables are marked with *. In the xsl coding you can access the value of a particular Local or Global Variable directly with $, a leading abbreviation vp and the name of the variable (<xsl:value-of select="$vpmystring"/>) if you activated the generation into the xsl or via the incoming message (<xsl:value-of select="/vpf:Msg/vpf:Header/vpf:Variables/vpf:var[./@id='mystring']/@value"/>). In the atom UIs you can note the Variables similar to the xPath notation with $name. Inside a concrete parameter field you can use one Variable multiple times and you can combine them with other Variables, Properties, etc.

A variable which is used inside the sql statement of a sql call atom will be checked during runtime to avoid cross-side scripting. In case the variable is in apostrophe, it is handled as a string, otherwise as a number. If the variable is not in apostrophe and not a number, the replaced value will be NaN. If you are using a variable e.g. for the table name, you can avoid this behavior by explicit type-casting the variable to a string with $string(variable-name).

4. In-Memory Variables
There are two types of in-memory variables available in B1if. Memory Variables Session Variables Memory Variables are used by developer during the design time to handover messages between multiple xform transformations. All the transformation stylesheets have read and write access during the complete processing flow. In addition Memory Variables can be used as placeholder for parameter definitions inside an atom UI. Session Variables are only available for Scenario Steps, processed by a synchronous HTTP call where the Scenario Package is specified to run in a session. Typically during the authentication phase the Session Variables are set and during the processing flows you can access the values. Technically all the transformation stylesheets have read and write access during the complete processing flow. In addition Session Variables can be used as placeholder for parameter definitions inside an atom UI.

Definition There is a container for Memory Variables and for Session Variables in B1if. The name of the session container is sessioninfo, the name for the memory container is ipobag. The In-Memory Variables are defined by adding a variable to this container. This can be done inside the stylesheet of a transformation atom or during authentication by just specifying a variable by using the xsl:variable command. The name of the variable doesnt matter.
<!-- set memory variable mem1 = ABC --> <xsl:variable name="memVar" select="document('/com.sap.b1i.internal.xc/xml/ipobag.xml?mem1=ABC')"/> <!-- set session variable sess1 = 123 --> <xsl:variable name="sessVar" select="document('/com.sap.b1i.internal.xc/xml/sessioninfo.xml?sess1=123')"/>

Scope Memory Variables are existent for the particular Scenario Step in which they are defined. The Memory Variables can be used during the complete process flow. Session Variables are existent with the first incoming HTTP call of a Scenario Package and are accessible from inside all Scenario Steps, triggered by synchronous HTTP and will expire with the session expiration. These are the only variables to be used to communicate between different Scenario Steps inside one session.

Assignment of Values Memory Variables and Session Variables are assigned with the same statement as the definition is done.
<!-- change value of memory variable mem1 to XYZ --> <xsl:variable name="memVar" select="document('/com.sap.b1i.internal.xc/xml/ipobag.xml?mem1=XYZ')"/> <!-- change value of session variable sess1 = 456 --> <xsl:variable name="sessVar" select="document('/com.sap.b1i.internal.xc/xml/sessioninfo.xml?sess1=456')"/>

Usage inside the Processing Flow You can use the Memory Variables and the Session Variables in your XSL coding and as placeholder in the atom UIs inside the parameter definition. All parameters supporting the variables are marked with *. In the xsl coding you can access the value of a Memory Variable directly with the following xPath statement
<xsl:value-of select="document('/com.sap.b1i.internal.xc/xml/ipobag.xml')/xci:ipo-bag /xci:key[./@name='mem1']/@value)"/> <xsl:value-of select="document('/com.sap.b1i.internal.xc/xml/sessioninfo.xml')/xci:sessioninfo/xci:key[./@name='sess1']/@value)"/>

In the atom UIs you can note the Memory Variables bracketed by parenthesis $(name), the Session Variables bracketed by double parenthesis $((name)). Inside a concrete parameter field you can use one Variable multiple times and you can combine them with other Variables, Properties, etc.

5. Message Values
Message Values are used by developer during the design time to handover messages between multiple xform transformations. All the transformation stylesheets have read and write access during the complete processing flow. In addition Message Values can be used as placeholder for parameter definitions inside an atom UI. Definition Each Flow Atom in the processing flow will add an own Payload section in the B1i message which is passed from one flow atom to the next. Inside the xsl stylesheet linked to a transformation atom in the flow you can produce your individual xml output. Each atom has a unique name (atom1, atom2, ).

Any transform atom can create any kind of xml structure, e.g. the following, which will be immediately available as a Payload section after the atom processing.
<root> <myheader>123</myheader> <positions> <posdef>definitions</posdef> </positions> </root>

Scope Once the section is created it will be part of the message till the end of the complete processing. After processing you always can access this information via the MessageLog (if switched on).

Assignment of Values Assignment of values is done in the transformation atom that created the data section. No following transformation can change it.

Usage inside the Processing Flow You can access the data section of any predecessor atom in your XSL coding and as placeholder in the atom UIs inside the parameter definition. All parameters supporting the message values are marked with *. In the xsl coding you can access any value of a predecessor data section directly via normal xPath statements. The following xPath statement shows how to access data, produced by atomx, based on our example above.
<xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@id=atomx]/root/myheader

In the atom UIs you can access element values from such a data section directly via the Message Values, noted with a leading $ and the name, bracketed by square bracket. You can just specify the name of an existing element or filtered to a particular atom output section. Inside a concrete parameter field you can use one Message Value multiple times and you can combine them with other Variables, Properties, etc.

6. SLD Properties
SLD Properties are used in the System Landscape Directory (SLD) to describe the connectivity parameters for a particular system. Definition The SLD Properties are pre-defined in the B1if repository. B1if provides you so called SysTypes which are linked to active and passive adapters. The connectivity is defined with the corresponding properties.
SysType B1.2004 B1.2005 B1.2007 B1.8.8 BI.3.5.3 BI.7.0.3 ECC6.0 F.AnySystem H.AnySystem J.AnySystem R3.46C R3.47.100 R3.47.200 W.AnySystem active Adapter B1DI B1DI, JDBC B1DI, JDBC B1DI, JDBC HTTA HTTA RFCA, WSAN, WSAS FILI HTTA JDBC RFCA RFCA RFCA WSAN, WSAS passive Adapter

RFCP, WSAO, WSAR FILO HTTP RFCP RFCP RFCP WSAO, WSAR

Scope SLD Properties are always existent as they are stored in an xml document. During runtime their values are available inside the processed B1i message for all Scenario Step.

Assignment of Values When you setup the environment on customer side, you will create the necessary entries in the SLD (SLD Create System). By selecting a SysType B1if will prompt you with the required properties to access the system via the linked adapters.

Usage inside the Processing Flow You can use the SLD Properties in your XSL coding. All properties you can also use in the atom UIs inside the parameter definition. All parameters supporting the SLD Properties are marked with *. In the xsl coding you can access the value of a particular SLD Property by using the xsl document function (which is overlaid by the B1i technology) to open the table document and with xPath statements you can select the data based on your needs.
<xsl:variable name="sysiddoc" select="document('/com.sap.b1i.system.sld.directory/SysId.xml/0010000101(Id)')"/> <xsl:variable name="url" select="$sysiddoc/sim:SysId/sim:ConnectivityList/sim:Connectivity [./@ConnectivityTypeId='JDBC']/sim:Parameter[./@Key='url']/@Value"/>

In the atom UIs you can note the SLD Property with $*sysid.adapter.property*

7. Config Properties
Definition Config Properties are used in B1if to specify general environment settings. There are two types of Config Properties, the Connectivity Parameters and the Runtime Parameters. Scope Config Properties are always existent as they are stored in an xml document. During runtime their values are available inside the processed B1i message for all Scenario Step.

Assignment of Values When you setup the general environment on customer side, optionally you will define the general parameters (Maintenance Cfg Connectivity and Maintenance Cfg Runtime).

Usage inside the Processing Flow You can use the Config Properties in your XSL coding. All properties you can also use in the atom UIs inside the parameter definition. All parameters supporting the properties are marked with *. In the xsl coding you can access the values of the Config Properties with the following xsl coding:
<!-- Connectivity.Internet: Proxy Host-->
<xsl:value-of select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')/vpf:vPlatform/vpf:webhost"/>

<!-- Connectivity.Internet: Proxy Port-->

<xsl:value-of select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')/vpf:vPlatform/vpf:webport"/>

<!-- Connectivity.Send Email: SMTP Server -->

<xsl:value-of select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')/vpf:vPlatform/vpf:smtpserver"/>

<!-- Connectivity.Send Email: SMTP Port -->

<xsl:value-of select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')/vpf:vPlatform/vpf:smtpport"/>

<!-- Connectivity.Send Email: SMTP User -->

<xsl:value-of select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')/vpf:vPlatform/vpf:smtpuser"/>

<!-- Connectivity.Send Email: SMTP Password -->

<xsl:value-of select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')/vpf:vPlatform/vpf:smtppwd"/>

<!-- Runtime.B1i HTTP Port -->

<xsl:variable name="cdoc" select="document('/com.sap.b1i.vplatform.ide/mode/mode.xml')"/> <xsl:choose> <xsl:when test="string-length($cdoc/vpf:vPlatform/http)=0">8080</xsl:when> <xsl:otherwise><xsl:value-of select="$cdoc/vpf:vPlatform/http"/></xsl:otherwise> </xsl:choose>

<!-- Runtime.B1i HTTPS Port -->

<xsl:choose> <xsl:when test="string-length($cdoc/vpf:vPlatform/https)=0">8443</xsl:when> <xsl:otherwise><xsl:value-of select="$cdoc/vpf:vPlatform/https"/></xsl:otherwise> </xsl:choose>

<!-- Runtime.B1i Server -->

<xsl:choose> <xsl:when test="string-length($cdoc/vpf:vPlatform/server)=0"> <xsl:value-of select="document('/com.sap.b1i.internal.xc/xml/hostname.xml')/*"/> </xsl:when> <xsl:otherwise><xsl:value-of select="$cdoc/vpf:vPlatform/server"/></xsl:otherwise> </xsl:choose>

In the atom UIs you can note the Config Property with $ and the name of the property wrapped with the ? character.

8. Global Properties
Global Properties are used in case you cannot hardcode a fix value, e.g. you provide your integration development for many customers and each of them will need a different setting or you want to allow your customer to frequently change the settings. During design time you introduce the properties, optional with a default value. During setup the customer set the values to his needs and the scenario is working accordingly. Definition The Global Properties you define with B1if Scenarios Step Design Definitions.
Processing Prop or

Scenarios Package Design

You can add and delete Global Properties and you can maintain the default values for these properties. These values are explicit values (literals) only.

To define a literal you can just type in the value. As numeric values will be interpreted as numbers, leading zeros will be deleted. Therefore you need to mark the string explicitly as a string (prop2). In addition you can specify a description which will be displayed on mouse move in the screen for the customer when he maintains his actual values for the properties. Its also possible to specify an enumeration (list of allowed values, separated by *) for the properties. In the setup screen the customer will have a drop-down list to select one of the defined values. This extended definition is currently not supported by the design UI. Please open the corresponding xml document directly with your xml editor and maintain the values to your needs. /com.sap.b1i.vplatform.scenarios.design/vPac.<name>/vProp.xml

Scope Global Properties are always existent as they are stored in an xml document. During runtime their values are available inside the processed B1i message for all Scenario Steps belonging to the Scenario Package. By default the Global Properties will be generated into the xsl stylesheet of a transformation atom which allows you to access them directly from your xsl coding. Optional you can de-activate the generation via Maintenance Cfg Dev Environment Generate Variables to XSL).

Assignment of Values During design time you specify the default values for the properties during the definition phase (Scenarios Step Design Processing Prop or Scenarios Package Design Definitions.). When you setup your Scenario Package on customer site you can overwrite the default values by using the setup screen Scenarios Setup [Data Mgt.] Properties.

This screen is generated automatically based on your definition during design time. You can see the two selection buttons [] to open a drop-down with the enumeration definition and you can see the filled description text displayed in the explanation area of the screen. All changes here will have immediate effect to the running scenarios.

Usage inside the Processing Flow You can use the Global Properties in your XSL coding. All properties you can also use in the atom UIs inside the parameter definition. All parameters supporting the properties are marked with *. In the xsl coding you can access the value of a particular Global Property directly with $, a leading abbreviation vp and the name of the property (<xsl:value-of select="$vpprop1"/>) if you activated the generation into the xsl or via the incoming message (<xsl:value-of select="/vpf:Msg/vpf:Header/vpf:Properties/vpf:prop[./@id='prop1']/@value"/>). In the atom UIs you can note the Global Property similar to the xPath notation with $name. Inside a concrete parameter field you can use one Global Property multiple times and you can combine them with other Variables, Properties, etc.

9. Global Tables
The Global Table, available with B1if 1.4.0 (B1 8.8.1 PL03) is a very powerful concept in B1if which is used in case simple properties do not cover your needs. Whenever you want to cover multiple entries, each with a set of values instead of one single value you can introduce a Global Table (of level 1). Global Tables (level 2) are supporting a structure of 1:n relationship; for both the parent and child segments you can define a set of values. One example could be a list of values, depending on combinations of sender and receiver systems. Definition The Global Tables you define with B1if Scenarios Package Design Tables.
Definitions Global

In the screen you can define multiple tables. When you open the screen, you will see a table holding one header entry for each existing Global Table definition for the particular Scenario Package. In the header entry you specify the structure of the Global Table. For better overview you can expand the definition with the [+] button to see all field definitions for this table and you can collapse the entry by clicking the [] button.

In the first screen the definition for a Global Table Type 1 is collapsed. In the second screen the definition for a Global Table Type 2 is collapsed. As you can compare Global Tables with database tables, B1if allows you - similar to a database system - to define the structure of the table(s). In addition B1if allows you to define the edit screen for this table which will be used later on customer site to allow the customer to maintain the values to his needs. Both, the structure definition and the definition of the setup screens are done in this definition screen. The definition of the setup screen supports labels, selection boxes, enumerations, plausibility checks and field length. The editor screen will be generated on the fly based on these definitions. You always can change the definitions and regenerate the tables. Existing values will not be overwritten. Overall buttons [New] Create a new definition for a Global Table [Delete] Delete the definitions for all Global tables which are checked [Generate] Create new tables and update existing tables [Clear] Delete all tables for which the definition doesnt exist anymore Header section Type Specifies if the table is of type 1 or 2. Global Tables type 1 you can compare with database tables. You define the structure and then you can add multiple records. Global Tables type 2 you can compare with 2 database tables with parent child relationship. Fields L1 Specifies the number of fields on the first level Fields L2 Specifies the number of fields on the second level ID Table identifier Name Name of the table Position section Level Indicator if the field belongs to the header or the child segment. The value is 1 or 2. This value is generated automatically. Field Number of the field. This value is generated automatically. Disp Len Length of the input field Max Len With the usage of max len, you can cut the entered value to the defined length. Selection B1if has some inbuilt selection function (e.g. system in the SLD) which can be used to allow the customer a comfortable selection via drop-down list. You also can specify the enumeration by listing all allowed values, separated by *. Label Optional text to be written in front of the field Check Optional you can use one of the inbuilt plausibility checks (e.g. IsNumber) to check the entered value.

Scope Global Tables are always existent as they are stored in an xml document. The scope of Global Tables is set to the Scenario Package which allows access for all Scenario Steps of this package. The Global Tables are stored as xml documents in the Scenario Package design path inside the B1if database (/com.sap.b1i.vplatform.scenarios.design/ vPac.name/vTbl.name.xml).

Assignment of Values The generated edit screens for the Global Tables can be called via the B1if setup screen Scenarios Setup [Data Mgt.] Table:vTbl.name . Here the customer can maintain his values.

In the first screen you see the edit screen for our Global Table Type 1 definition and in the second screen the edit screen for our Global Table Type 2 definition. If you check this generated edit screens with the definition screens you will see that the generated screens are following the definition above. The structure and number of fields is as specified, you can see the defined labels and you will find [] buttons for all fields where you defined a selection. Insert Delete This button allows the customer to add a new record to the table. In case of type 2 tables you will find the [Insert] button on both levels. This button allows the customer to delete all checked entries.

As mentioned above, the Global Tables are stored as xml documents in the Scenario Package design path inside the B1if database (/com.sap.b1i.vplatform.scenarios.design/ vPac.name/vTbl.name.xml). As an example you see an excerpt from the defined type 2 table.
<table xmlns="" len="10,10,5,5,15" L1="2" L2="3" level="2" name="myTable3"> <?com.sap.b1i.system_import protect?> <sel id="1" label="Header 1" plaus="" max="10">Systems B1</sel> <sel id="2" label="Header 2" plaus="" max="10">Systems R3</sel> <sel id="3" label="Pos 1" plaus="" max=""/> <sel id="4" label="Pos 2" plaus="IsAlpha" max=""/> <sel id="5" label="Pos 3" plaus="" max=""/> <row open="true"> <col>0010000103</col> <col>0010000109</col> <row> <col>111</col> <col>a</col> <col>122</col> </row> <row> <col>222</col> <col>b</col> <col>244</col> </row> <row> <col>333</col> <col>c</col> <col>67</col> </row> </row> ...

Usage inside the Processing Flow Global Tables can easily be accessed during the processing flow from each of the xsl transformations by using the xsl document function (which is overlaid by the B1i technology) to open the table document and with xPath statements you can select the data based on your needs.

<xsl:variable name="mytbl1" select="document('/com.sap.b1i.vplatform.scenarios.design/vPac.name/vTbl.myTable1.xml')"/> <xsl:variable name="mytbl3" select="document('/com.sap.b1i.vplatform.scenarios.design/vPac.name/vTbl.myTable3.xml')"/>

...
<xsl:value-of select="$mytbl1/table/row[2]/col[3]"/> <!-- A --> <xsl:value-of select="$mytbl3/table/row[1]/row[2]/col[3]"/> <!-- 244 -->

You can also use the Global Tables inside the parameter definition of an atom. All parameters supporting the Global Tables are marked with *. In the atom UIs you can note the Global Tables following the supported syntax. Inside a concrete parameter field you can use one Global Table entry multiple times and you can combine them with other Variables, Properties, etc. ${tbl[row,col]} ${tbl[row,row,col]} Placeholder for the value of a Global Table Type 1. row can be a number (e.g. 2) or a condition (e.g. 2=233 or 2=233) Placeholder for the value of a Global Table Type 2 row can be a number (e.g. 2) or a condition (e.g. 2=233 or 2=233)

Copyrights, Trademarks, and Disclaimers

Copyright 2011 SAP AG. All rights reserved.

The current version of the copyrights, trademarks, and disclaimers at http://service.sap.com/smb/sbocustomer/documentation is valid for this document.