Bidirectional script enablement in IBM® WebSphere® Adapters occurs at different levels and through different component configurations. Bidirectional enablement is actualized on the three following levels:

• Through the correct displaying and typing of bidirectional script characters, using Enterprise Metadata Discovery (EMD)
• Through the correct storage of bidirectional characters, using when necessary the code page translation for converting bidirectional characters from one format to another (between Unicode code set and single-byte code set)
• Through using bidirectional text transformations to translate between the Windows® bidirectional format (the format used in WebSphere Process Server) and different bidirectional formats used in external applications.

The following sections present detail on each of these levels and how bidirectional script enablement is realized on them.

Correct handling of bidirectional data in the EMD GUI

This section covers only the GUI aspect of support for bidirectional scripts in EMD. For other aspects (for example, enablement for bidirectional text transformation) see the section below on bidirectional scripts enablement in EMD.

EMD is a tool based on the Eclipse technology and provided as part of WebSphere Integration Developer. It is used to rapidly unlock metadata information in an Enterprise Information System (EIS). Using EMD, developers are able to gather information about the data and functions of an EIS.

EMD walks the developer through a series of screens to gather all the necessary information (from both the developer and the EIS with which EMD is communicating) before it generates the artifacts. Bidirectional script data can appear in EMD in the following three cases:

• Parts of the EMD screens that were translated to one of the languages having bidirectional scripts (for example, labels or titles that are translated into Arabic). Figure 1 shows an example of JDBC EMD, illustrating this case.
  Figure 1. EMD - translation
  
  
• Connection properties specified on the first EMD screen: Configure Settings For Discovery Agent (for example, User Name for all adapters, Connection String for Siebel or JDBC adapter). Figure 2 shows an example of PeopleSoft EMD, illustrating this case.
  Figure 2. EMD first screen bidi data
  
  
• EIS metadata displayed to the user on the second EMD screen: Find and Discover Enterprise Services (for example, Business Services Names in Siebel, Tables or Views names in JDBC). Figure 3 shows an example of Siebel EMD, illustrating this case.
  Figure 3. EMD second screen bidi data
  
  

EMD is able to correctly display bidirectional characters due to basic capability in WebSphere Integration Developer. No special configuration except for character code set definition is required. For details on the required configuration of WebSphere Integration Developer for enabling bidirectional scripts, see "Bidirectional support in IBM WebSphere Integration Developer" (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwid.html).

Back to top

Locale support in IBM WebSphere Adapters

IBM WebSphere Adapters are executed in the WebSphere Process Server environment. Consequently, with respect to processing local dependent data including bidirectional data, they depend to a large degree on WebSphere Process Server capabilities. For details on the specifics of locale support in WebSphere Process Server (with respect to bidirectional script data processing), as well as for operating in the multilingual environment and processing multilingual data, see "Overview of bidirectional script support in WebSphere Process Server" (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwps.html).

This document covers specifics of locale dependent data processing (in the context of bidirectional script data) that are unique to IBM WebSphere Adapters. Bidirectional data is processed within IBM WebSphere Adapters at three levels:

• Content data: business data retrieved or sent to or from an EIS by an adapter
• Meta and configuration data: data used by an adapter for establishing and maintaining a communication link to the specific EIS:
  • connection properties in the adapter deployment descriptor (ra.xml), including the configuration properties of Resource Adapter (RA), Managed Connection Factory (MCF), and Activation Specification (AS)
  • Application Specific Information (ASI) on the DataObject and DataObject attribute levels as part of the DataObject definition
• Log and trace data

The content data level processes the data object runtime data. The meta and configuration level processes the data used by connectors to establish and maintain communication with the EIS. The log and trace data level processes informational messages logged into various logs and trace files. To assure the correct handling of bidirectional script data on those levels, the correct character code set should be chosen and configured. The sections below explain the character code set considerations and configuration options for each of these levels.

Content data character code set

Internally, adapters and WebSphere Process Server use Unicode for data presentation and storage. However, to successfully exchange data with external systems using a single-byte code page, adapters must provide a conversion between internal (Unicode) and external (either Unicode or a single-byte code page) presentation of data. Content data can be passed in both directions: either from WebSphere Process Server via adapter to the EIS or from the EIS via adapter to WebSphere Process Server. Consequently, conversion between internal and external presentation of data should be made for both of those directions.

There are several components for which configuration of the character code set should be performed. First, the character code set on WebSphere Process Server must be set to Unicode. For more details on how to set the character code set on WebSphere Process Server for processing multilingual data (including bidirectional data), see "Overview of bidirectional script support in WebSphere Process Server" (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwps.html). Second, the adapter must be configured to use the character code set that matches the one used by the EIS. By default, the adapter would use the character code set inherited from WebSphere Process Server. This means that adapters would inherit this character code set for all communication channels they establish (including a communication channel to the EIS). However, if the EIS does not support the Unicode character code set, it is necessary either to open a communication channel using a single-byte code page or to convert the data passed to the EIS into the supported code page.

Different adapters have different levels of flexibility with respect to available character code set configuration. For example, for the JDBC adapter it is possible to specify the character code set using the JDBC driver parameters. A connector for PeopleSoft or Siebel, on the other hand, has limited character code set support provided by the client API. Consequently, there are currently two approaches that can be used to handle content data character code set support. These approaches are:

• Automatically handling encoding by middleware or third party APIs used for serialization and deserialization of data objects (for example PeopleSoft and Siebel client APIs)
• Using the underlying technology that has the appropriate configuration for the connector (for example, character code set parameters that can be passed to the JDBC driver in the JDBC connector)

For details on what approach is taken by a specific adapter, see the adapter user guide.

Be aware that in a multilingual environment converting Unicode data into a single-byte code page might result in a loss of data, because not every character in the Unicode character code set has an equivalent in the single-byte code page. In other words, if the Unicode data includes data from more than one non-Latin language, the conversion will definitely result is the loss of some data, depending on the type of single-byte code page chosen. However, if only one non-Latin language is used and the appropriate single-byte code page is selected, data loss will not occur.

Meta and configuration data character code set

In the WebSphere Process Server environment, metadata is usually stored in the Unicode character code set. In the EIS, it might be stored in a different character code set. Meta and configuration data is used by the connector in the communication with the EIS only. Thus, the only direction of metadata flow for which the character code set transformation should take place is from WebSphere Process Server to the EIS.

The support for the data character code set configuration for meta-configuration data often depends on the capabilities of the middleware the adapter code uses for setting up a connection to the EIS. The meta and configuration data specified in WebSphere Integration Developer and/or the WebSphere administrative console (as part of the RA/MCF/AS properties configuration or ASI on BO and attribute levels) is stored as Unicode. At runtime, this data is used as an argument for either native Java™ APIs or third party APIs to establish a communication link with an external source. The middleware used for establishing a communication link in the adapter code can range from native Java APIs or packages to third party APIs. Because neither native Java APIs, third party APIs, nor middleware is guaranteed to support an explicit encoding specification, adapters only support Unicode encoding for meta and configuration bidirectional data.

The definition of character code set used with metadata is inherited by adapters from WebSphere Process Server. For details on how to set the character code set on WebSphere Process Server for processing multilingual data (including bidirectional data) see "Overview of bidirectional script support in WebSphere Process Server" (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwps.html).

Log and trace data character code set

By default, the character code set of the bidirectional data flashed out into the log and trace files is inherited from WebSphere Process Server. See "Overview of bidirectional script support in WebSphere Process Server" (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwps.html) for how to set the character code set for log and trace files in WebSphere Process Server. To store multilingual data (including bidirectional data) in log and trace files, the character code set on WebSphere Process Server should be set to Unicode.

Back to top

Enabling adapters for bidirectional text transformation

Enablement of adapters for bidirectional text transformation allows them to correctly exchange bidirectional data with EIS systems, on which it can be represented in a different bidirectional format. Bidi properties are used for specifying bidirectional format values for various entities, properties, or attributes of an adapter module and data object. Those properties are used at runtime for the correct processing of bidirectional data represented on various EIS systems in various bidirectional formats. Invocation of support for bidirectional text transformation is controlled by values assigned to bidi properties.

Important aspects of support for bidirectional text transformation in adapters are:

• Flexibility: Bidi properties allow you to control invocation of bidirectional transformation on every level separately and independently.
• Ease of use: A look-up mechanism allows you to control support for bidirectional text transformation for the majority of entities and properties by completing just a few steps.
• Accuracy: The implementation of support for bidirectional text transformation allows you to perform "smart" bidirectional transformation of values that require special treatment.

Specifying bidi properties

Figure 4 schematically depicts the hierarchy of levels on which bidi properties can be specified.

Bidi properties are divided into four types:

• EIS: Properties of this type are used to indicate the bidirectional format for content data.
• Metadata: Properties of this type are used to indicate the bidirectional format for metadata.
• Skip: Properties of this type are used to indicate whether or not to invoke the support for bidirectional text transformation.
• SpecialFormat: Properties of this type are used to indicate the special formatting requirements of this property (for example, file paths, JDBC URL). For these cases, bidirectional transformation should be applied in a smart way in order not to corrupt the syntax of the values. Such special case categories are discussed below.
• BiDiTurnOff: A flag that controls the invocation of bidirectional transformation for the resource adapter. Used only on the RA level.

Note that the naming convention of properties may vary depending on the level and context (for example, RA/MCF/AS bean property name, property name as it appears in EMD GUI). For the exact names of properties used by the adapter on various levels, see the specific adapter user guide.

Not all property types are present or used on all levels. Table 1 shows which properties are appropriate at each specification level.

At the Resource Adapter level, you can specify the following properties:

• EIS: Bidirectional format for content data either processed by or stored in all entities starting from RA and lower in the hierarchy depicted in Figure 4.
• Metadata: Bidirectional format for metadata or configuration data processed by or stored in all entities starting from RA and lower in the hierarchy depicted in Figure 4.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the RA level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.
• BiDiTurnOff: A flag that controls the invocation of bidirectional transformation for the resource adapter. If this property's value is set to true, no bidirectional transformation occurs, regardless of values in other bidi properties.

At the Managed Connection Factory (MCF) level, you can specify the following properties:

• EIS: Bidirectional format for content data either processed by or stored in all entities starting from MCF and lower in the hierarchy depicted in Figure 4.
• Metadata: Bidirectional format for metadata or configuration data processed by or stored in all entities starting from MCF and lower in the hierarchy depicted in Figure 4.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the MCF level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the Activation Spec (AS) level, you can specify the following properties:

• EIS: Bidirectional format for content data either processed by or stored in all entities starting from AS and lower in the hierarchy depicted in Figure 4.
• Metadata: Bidirectional format for metadata or configuration data processed by or stored in all entities starting from AS and lower in the hierarchy depicted in Figure 4.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the AS level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the RA connection configuration property level, you can specify the following properties:

• EIS: Bidirectional format for this property.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the RA connection configuration property level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the MCF connection configuration property level, you can specify the following properties:

• EIS: Bidirectional format for this property.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the MCF connection configuration property level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the AS connection configuration property level, you can specify the following properties:

• EIS: Bidirectional format for this property.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the AS connection configuration property level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the DataObject level, you can specify the following properties:

• EIS: Bidirectional format for content data as defined by the EIS and used to populate this DataObject.
• Metadata: Bidirectional format for all levels of ASI in this data object.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the Data Object level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the DataObject ASI attribute level, you can specify the following properties:

• Metadata: Bidirectional format of the specific ASI attribute.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the Data Object ASI attribute level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the DataObject Attribute level, you can specify the following properties:

• EIS: Bidirectional format for content data as defined by the EIS and used to populate this DataObject Attribute.
• Metadata: Bidirectional format for all levels of ASI in this data object.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the DataObject Attribute level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

At the Data Object Attribute ASI attribute level, you can specify the following properties:

• Metadata: Bidirectional format of the specific ASI attribute.
• Skip: A flag that controls the invocation of bidirectional text transformation support at the Data Object Attribute ASI attribute level. If Skip is true, the support is not invoked. If Skip is false, the support is invoked.
• SpecialFormat: Specifies the category of bidi properties values that require special treatment. See Table 4 for a list of possible values.

Bidi properties on the following levels can be initialized using EMD and can be further edited and tuned using Assembly editor at design time and using WebSphere Application Server administrative console at deployment time:

• Resource Adapter (RA)
• RA connection configuration properties
• Managed Connection Factory (MCF)
• MCF connection configuration properties
• Activation Spec (AS)
• AS connection configuration properties

Bidi properties on the following levels can be added and edited using Business Object Designer:

• DataObject
• DataObject ASI attribute
• DataObject Attribute
• DataObject Attribute ASI attribute

Scope of bidi properties definition

As described in the previous section, bidi properties can be specified on various hierarchically interrelated levels. The applicability of a specific bidi property is not limited to the specific level on which it was defined. The applicability of a bidi property is defined by its scope, as illustrated in Figure 5:

Legend:

• A dotted line connecting two entities on the diagram signifies association/usage. For example, MCF/AS are associated with BOs, or RA uses MCF/AS.
• A solid line connecting two entities on the diagram signifies an inclusion relationship. For example, BO includes Attributes, or RA includes properties.
• The colored triangles signify the scope of a bidi property for given level.

A scope defines the portion of the hierarchy that is covered by a particular property. The scope applies separately for each of four types of bidi properties (EIS, Metadata, Skip, and SpecialFormat).

• The scope of a specific bidi property (regardless of its type) for RA/MCF/AS connection configuration properties is limited only by the specific RA/MCF/AS connection configuration property for which it was defined.
• The scope of a specific bidi property (regardless of its type) for RA/MCF/AS includes all levels starting from RA/MCF/AS and lower according to Figure 4. For example, the scope for RA includes RA connection configuration properties, MCF, MCF connection configuration properties, AS, AS connection configuration properties, Data Object, Data Object Attribute, and Data Object Attribute ASI metadata attribute.
• The scope of a specific bidi property (regardless of its type) for Data Object includes Data Object, Data Object Attribute, Data Object Attribute ASI metadata attribute.
• The scope of a specific bidi property (regardless of its type) for Data Object ASI attribute is limited only by the specific Data Object ASI attribute for which it is defined.
• The scope of a specific bidi property (regardless of its type) for Data Object Attribute includes Data Object Attribute, Data Object Attribute ASI attributes.
• The scope of a specific bidi property (regardless of its type) for Data Object Attribute ASI attribute is limited only by the specific Data Object Attribute ASI attribute for which it is defined.

Since scopes are hierarchically interrelated, they are nested one inside another. For example, MCF or AS scopes include DataObject scope. RA scope includes both MCF, AS, and DataObject scopes. To determine the specific value for a specific bidi property on a specific level (taking into consideration the involved scopes) a mechanism called look-up is used. In this scheme, we start with the most local scope and increase the scope upward one level at a time until a value is found. If no value is found, the default value is used. The look-up mechanism is described in more detail in the next section.

Look-up mechanism

The look-up mechanism looks at the scopes starting from the current one upwards. For example, for DataObject it would inspect DataObject scope, then either MCS or AS scope, and finally RA scope. The first scope in which a value is found for a bidi property is the one that defines the de facto value of the specific property. For example, if we assume that only RA level properties have values, then for all properties on all other levels, values of properties will be taken from the RA level.

Important observation: For different types of bidi properties (for example, EIS, Metadata) the de facto level from which the value is taken may be different. For example, if the EIS format is defined only on the RA level, while Metadata is defined only on the DataObject level (and no other values are defined on any other levels), for DataObject attributes not having EIS nor Metadata value, the DataObject level value will be used for Metadata, and RA level value will be used for EIS.

Precedence and scope inform how the look-up mechanism derives a value for a bidi property that is nested in one or more levels.

Precedence of the bidi property value

The highest precedence for all bidi properties is the value of the BiDiTurnOff property. If it equals true, then support for bidirectional text transformation is excluded, regardless of any values bidi properties might have on various levels. If it equals false, then other values for bidi properties on various levels are considered.

For each specific type of bidi property and specific level on which it is defined (for example, the EIS type of bidi property defined on the MCF level), the value specified for a property at that level has highest precedence over all values specified for the same type of bidi properties on all other levels. In other words, if a value for a bidi property is defined and is legal, then it is used. For example, if EIS on MCF has a value ILYNN, this value is used. See the tables below for a list of bidi property values. The following sections explain what happens if a value is missing or incorrect.

What happens if a value is missing

If the value for a specific property on a specific level is missing, the hierarchy (as depicted in the Figure 4) is searched upward until a value for this type of bidi property is found. If the topmost level is reached and no value is found, the default value is used. Here are a few important points regarding the hierarchy traversal and lookup:

• The hierarchy is searched only for properties of the same bidi property type as the missing type value.
• The hierarchy is searched upward from child to parent only; siblings are not considered.
• The hierarchy traversal is such that there can be a single path only from any child to the root of the hierarchy, as seen in these data paths:
• Data Object Attribute ASI attribute --> Data Object Attribute --> Data Object --> Activation Specification (AS) --> Resource Adapter (RA)
• Data Object Attribute ASI attribute --> Data Object Attribute --> Data Object --> Managed Connection Factory (MCF) --> Resource Adapter (RA)
• Data Object ASI attribute --> Data Object --> Managed Connection Factory (MCF) --> Resource Adapter (RA)
• Data Object ASI attribute --> Data Object --> Activation Specification (AS) --> Resource Adapter (RA)
• AS connection configuration properties --> Activation Specification (AS) --> Resource Adapter (RA)
• MCF connection configuration properties --> Managed Connection Factory (MCF) --> Resource Adapter (RA)
• RA connection configuration properties --> Resource Adapter (RA)

What happens if the bidi property is not defined for a specific level?

Since not all types of bidi properties (EIS, Metadata, Skip, and SpecialFormat) are defined at all levels, the look-up mechanism may not find a bidi property type at the specific level. If this occurs, the look-up mechanism concludes that the property is missing and moves to the next (higher) level. If the look-up mechanism reaches the top level and no property is found, the default value is used.

What happens if a value is incorrect?

If a bidi property has an invalid value on the RA/MCF/AS levels, a verification mechanism is invoked and the exception is fired. If a bidi property has an invalid value on the DataObject and lower levels, the default value is taken and no look-up at higher levels is performed.

Values subject to special treatment

Explicit bidirectional transformation of FTP URL and e-mail addresses can result in inaccurate interpretation. To avoid this, the look-up mechanism analyzes such data strings, identifying problematic subcomponents within the string values, before transformation occurs. In cases where problematic subcomponents are identified, the string is split, and bidirectional transformation is applied on each of the subcomponents. After the transformation process has completed, the subcomponents are reassembled into a single string that represents the accurately transformed value. This value is then stored for later use. To identify the category of values subject to special treatment (for example, FTP URL or e-mail address), use the SpecialFormat bidi property, when appropriate. The list of currently supported categories subject to special treatment is shown in Table 4.

Possible and default values for bidi property types

The tables and sections below describe the possible values for bidi type properties.

Bidi properties of type EIS and Metadata hold a bidirectional format specification that is represented by a five-letter string. Valid values for the bidi format are listed in the Table 2:

Bidi properties of type Skip can accept the values indicated in Table 3 (the default value is true):

Bidi properties of type SpecialFormat can accept the values indicated in Table 4 (the default value is NORMAL_STRING):

Back to top

Enablement for bidirectional text transformation in EMD

In the WebSphere Process Server environment, bidirection data is stored in one standard bidirectional format, which is identical to the Windows standard bidirectional format (logical, left-to-right). In the EIS, bidirectional data might be stored in a different bidirectional format. Thus, when bidirectional data is passed between the WebSphere Process Server environment and the EIS, its bidirection format must be enforced.

EMD communicates with the EIS and retrieves metadata information from it. Consequently it must take into consideration the enforcement of the bidirectional format while exchanging data with the EIS. Enablement for bidirectional text transformation occurs in several places in EMD. To enable EMD for bidirectional text transformation you should:

1. Select the BiDi Transformation option on the first EMD screen, Configure Settings for Discovery Agent, as shown in Figure 6.
   Figure 6. EMD first screen bidi properties
   
   
2. Define the bidirectional format, using the following four properties appearing on the same screen: BiDi Ordering Schema, Direction, Symmetric Swapping, Shaping, Numeric Shaping. For more details on what bidirectional format means, see "Overview of bidirectional script support in WebSphere Process Server" (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwps.html).

Bidirectional format defined on the first screen is used by EMD to provide bidirectional text transformation support for sign-on EMD properties and EIS meta information.

• EMD sign-on properties are those connection-specific properties that EMD uses to establish a communication link to the EIS (for example, User Name, Password, Connection String). Not all EMS sign-on properties are enabled for bidirectional text transformation. For an exact list of adapter-specific sign-on properties enabled for bidirectional text transformation, see the specific adapter user guide. On the level of EMD sign-on properties, support for bidirectional text transformation is realized in the bidirectional format transformation applied by EMD on the values of sign-on properties enabled for bidirectional text. Bidirectional layout transformation transforms values from the Windows standard bidirectional format (the format in which they are defined in the EMD itself) to the bidirectional format in which they are defined on the EIS (this format is specified by the user in the EMD's first screen, as described above).
• EIS meta information is retrieved by EMD from the EIS and displayed to the user on the third EMD screen, Find and Discover Enterprise Services. Not every EIS type provides support for bidirectional data on the metadata level. For example, DB2 RDBMS provides support for bidirectional data on Table, Views, and other levels; Siebel provides support for bidirectional data on Business Service Names and other levels. However, neither PeopleSoft nor SAP provides any support for bidirectional data on the metadata level. Consequently, EMD will support bidirectional text transformation only for those EISs that support bidirectional data on the metadata level. For details on the specific metadata level on which a specific EIS provides support for bidirectional data, see the specific adapter user guide.

  On the level of EIS meta information, support for bidirectional text transformation is realized in the bidirectional format transformation applied by EMD on the EIS entities names (for example, Tables name in JDBC adapter, Business Service Names in Siebel adapter). Bidirectional layout transformation transforms the EIS meta information from the bidirectional format in which they are represented on theEIS (this format is specified by the user in the EMD on the first screen, as described above) to the Windows standard bidirectional format (the format in which they are represented in the WebSphere Process Server environment).

  Figure 7 shows how the Siebel Business Service Name, including bidirectional data, is displayed on the third Siebel EMD screen:

  
  Figure 7. Siebel entities with bidi data
  
  

The result of EMD's work is generated artifacts used by adapters at runtime. As part of those artifacts, properties controlling the invocation of the bidirectional transformation engine are provided. Specifically, bidi properties for RA, MCF, and AS levels are generated. Those properties appear on the last EMD screen, Generate Artifacts (select the "Use discovered connection properties option" to make them visible). Using this screen you can assign values to those properties.

The following points are general to all adapters' EMD:

• Properties from the RA level holding a bidirectional format value are initialized with the bidirectional format value defined on the first EMD screen (how the bidirectional format is defined on the first EMD screen, Configure Settings for Discovery Agent, was described above).
• Properties from the RA level only are initialized. Properties from the other levels (MCF and AS) are left empty. For any level below the RA level that specific handling for bidirectional text transformation is required (for example, using a different bidirectional format, skipping bidirectional transformation for a specific attribute) fine tuning of bidi properties can be performed. However, by default, thanks to the look-up mechanism, the RA level values will be taken if no tuning is necessary or performed.
• The properties that can be configured on the last EMD screen can be also configured using Assembly Editor after EMD finishes generating all the artifacts.
• On the first EMD screen, Configure Settings for Discovery Agent, the bidirectional format can be conveniently specified using a predefined list of values for each of its subcomponents (Bidi Ordering Schema, Direction, Symmetric Swapping, Shaping, Numeric Shaping; values of all those properties together constitute one bidirectional format). However, on the last EMD screen, Generate Artifacts, the bidirectional format is specified as one single value having a free format. The value of the bidirectional format is supposed to be a five letter string (for example, ILYNN), each letter of which (I or L or Y or N) signifies the value for its specific subcomponent (for example, I for Bidi Ordering Schema, L for Direction). For a list of allowed values for each subcomponent of bidirectional format value, see the appropriate table in this document.
• The format specified on the first EMD screen reflects the EIS standard for bidirectional format for metadata. Note that for content data, you can specify a different bidirectional format on the last EMD page. EMD itself does not manipulate content data, and therefore its specification would not make sense. The user is expected to have a prior knowledge of the EIS bidirectional format standard for both content and metadata before configuring and running EMD.

  Note also that if you wish to define a different bidirectional format for metadata on different levels:

  • You have to change the definition of bidirectional format for metadata on the desired level (either with Assembly editor or with Business Object Designer, depending on the level).
  • You have to change the values of ASI generated by EMD with Business Object Designer (BOD) to match the new definitions of bidirectional format for metadata on the same level. This is necessary for the following reason. EMD generates all ASI values using one bidirectional format. To change this format for a certain level, the ASI values on that level should be changed as well. However, there is no other way to do it except manually with BOD.

For different adapters, the list of bidi properties that can be configured in EMD might vary. For an exact list of bidi properties for specific adapters, see the adapter user guide. Figure 8 and Figure 9 show the RA and MCF level bidi properties in the Siebel EMD:

Back to top

Configuration of enablement for bidirectional text transformation in Business Object Designer

Business Object Designer (BOD) can specify values for properties controlling the invocation of support for bidirectional text transformation on the following levels:

• Data Object
• Data Object ASI attribute
• Data Object Attribute
• Data Object Attribute ASI attribute

Follow these steps to specify values for properties controlling the invocation of support for bidirectional text transformation on the Data Object level:

1. Select BO in the BOD designer view.
2. Select the Application Info tab in the Properties view.
3. Add the ASI type appropriate to your connector, using the Add button (for example, "Siebel ASI schema" for the Siebel adapter). To see the ASI schema of your connector in the list of available ASI types, the connector RAR file must be imported into the workspace in advance.
4. Select the ASI element you want to add (for example, SiebelBusinessObjectTypeMetadata for the Siebel adapter). Figure 10 illustrates the result for the Siebel adapter.
   Figure 10. DataObject level ASI definition screen
   
   
5. Right click the root of the ASI elements properties tree.
6. Select Add Child and then BiDiContext. Figure 11 shows the result for the Siebel adapter.
   Figure 11. Adding bidi properties on the DataObject level
   
   
7. Open the newly added child element. Note that it includes the four following child elements:
   • BiDiEIS
   • BiDiMetadata
   • BiDiSkip
   • BiDiSpecFormat
8. Using the dropdown comboxes with predefined lists of values, set the appropriate values for all these properties. Figure 12 shows the result of sample editing for the Siebel adapter.
   Figure 12. Editing bidi properties on the DataObject level
   
   

Follow these instructions to specify values for properties controlling the invocation of support for bidirectional text transformation on the Data Object ASI attribute level:

1. Follow steps 1-5, above.
2. Select Add Child and then the appropriate ASI attribute. For example, with the Siebel adapter, select BiDiContextBSN to add bidi properties for the BSN DataObject ASI attribute. Figure 13 illustrates the result for the Siebel adapter.
   Figure 13. Adding bidi properties on the DataObject ASI attribute level
   
   
3. Follow steps 7-8, above. Figure 14 shows the result of sample editing for the Siebel adapter.
   Figure 14. Editing bidi properties on the DataObject ASI Attribute level
   
   

Follow these instructions to specify values for properties controlling the invocation of support for bidirectional text transformation on the Data Object Attribute level:

1. Select the BO Attribute in the BOD designer view.
2. Select the Application Info tab in the Properties view.
3. Select the ASI type appropriate to your connector (for example, "Siebel ASI schema" for the Siebel adapter). To see the ASI schema of your connector in the list of available ASI types, the connector RAR file must be imported into the workspace in advance and the ASI type should be already added on the Data Object level.
4. Select the ASI element you want to add (for example, SiebelAttributeTypeMetadata for the Siebel adapter). Figure 15 shows the result for the Siebel adapter.
   Figure 15. DataObject Attribute level ASI definition screen
   
   
5. Right click the root of the ASI elements properties tree.
6. Select Add Child and then BiDiContext. Figure 16 shows the result for the Siebel adapter.
   Figure 16. Adding bidi properties on the DataObject Attribute level
   
   
7. Open the newly added child element. Note that it includes the four following child elements:
   • BiDiEIS
   • BiDiMetadata
   • BiDiSkip
   • BiDiSpecFormat
8. Using the dropdown comboxes with predefined lists of values, set the appropriate values for all these properties. Figure 17 shows the result of sample editing for the Siebel adapter.
   Figure 17. Editing bidi properties on the DataObject Attribute level
   
   

Follow these instructions to specify values for properties controlling the invocation of support for bidirectional text transformation on the Data Object Attribute ASI attribute level:

1. Follow steps 1-5, above.
2. Select Add Child and then the appropriate ASI attribute. For example, with the Siebel adapter you select BiDiContextFN to add the bidi properties for FN DataObject Attribute ASI attribute. Figure 18 shows the result for the Siebel adapter.
   Figure 18. Adding bidi properties on the DataObject Attribute ASI attribute level
   
   
3. Follow steps 7-8, above. Figure 19 shows the result of sample editing for the Siebel adapter.
   Figure 19. Editing bidi properties on the DataObject Attribute ASI attribute level
   
   

Note the following points:

• To add properties to the DataObject and Attributes levels, follow the same instructions given above for all adapters that provide bidirectional support specification options on those levels.
• To add properties to the Data Object ASI attribute and Attribute ASI attribute levels, the instructions above might be helpful. However, the names of ASI attributes that were enabled for bidirectional text transformation might very among adapters. For an exact list of ASI attributes enabled for bidirectional text transformation, see the specific adapter user guide.

Back to top

Configuration of enablement for bidirectional text transformation in Assembly Editor

Assembly Editor can be used to edit values for properties controlling the invocation of support for bidirectional text transformation on the following levels:

• RA
• RA connection configuration property
• MCF
• MCF connection configuration property
• AS
• AS connection configuration property

For an exact list of the properties that can be configured for each adapter, see the specific adapter user guide. Figure 20 and Figure 21 show properties from the RA and MCF levels present in the Siebel adapter:

Note the following points:

• Bidi properties that can be configured in Assembly Editor are initialized in the last EMD screen, Generate Artifacts, and therefore might already have values when they appear in Assembly Editor.
• Very similar to the last EMD screen in Assembly Editor, bidirectional format is specified as one single value having a free format. The value of the bidirectional format is supposed to be a five-letter string (for example, ILYNN), each letter of which (I or L or Y or N) signifies a value for its specific subcomponent (for example, I for BiDi Ordering Schema, L for Direction). For a list of allowed values for each subcomponent of the bidirectional format value, see the appropriate table in this document.

Copyright(c) IBM Corporation, 2005

Trademarks

IBM, Aptiva, DB2, and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product or service names may be trademarks or service marks of others.

Resources

Learn

• Bidirectional script support: A primer: An introduction to the concepts and peculiarities of bidirectional scripts in computing systems, which forms a basis for understanding how those scripts are implemented in specific systems (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidigen.html).
  
  
• Overview of bidirectional script support in IBM WebSphere Process Server: Specific bidi information about WebSphere Process Server (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwps.html).
  
  
• Overview of bidirectional script support in IBM WebSphere Integration Developer: An overview of support for bidirectional scripts in WebSphere Integration Developer (http://www.ibm.com/developerworks/websphere/library/techarticles/bidi/bidiwid.html).
  
  
• Globalize your On Demand Business: An executive overview of bidirectional languages.
  
  

Get products and technologies

• Unicode Bidirectional Algorithm: The layout transformations use a bidirectional implicit algorithm that conforms to the Unicode Bidirectional Algorithm.
  
  
• Bidirectional support in IBM SDK Version 1.4.1: IBM bidi layout transformation is implemented in IBM Java SDK Version 1.4.1.
  
  

About the author

Tomer Mahlin is a technical team lead who for the past six years has been deeply involved in projects concerned with bidirectional enablement in IBM and non-IBM products. Tomer has been working with WebSphere Business Integration products for the last three years and was one of the chief architects who designed bidirectional enablement in WebSphere Business Integration Adapters and in IBM WebSphere Adapters.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Correct handling of bidirectional data in the EMD GUI
• Locale support in IBM WebSphere Adapters
• Enabling adapters for bidirectional text transformation
• Enablement for bidirectional text transformation in EMD
• Configuration of enablement for bidirectional text transformation in Business Object Designer
• Configuration of enablement for bidirectional text transformation in Assembly Editor
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers