IBM(R) WebSphere(R) Service Flow Modeler Technology Preview - Readme file

Welcome to the IBM WebSphere^(R) Service Flow Modeler Technology Preview, powered by Eclipse technology.

To view the latest version of this readme file, go to this Web address: ftp://ftp.software.ibm.com/ps/products/wsed/TechPreviews/SFM/readme.html

This file is available in the following national languages:

General release notes

1. Supported software
   1. Running with IBM WebSphere Business Integration Message Broker is not supported

      Installing and running the Service Flow Modeler Technology Preview and the IBM WebSphere Business Integration Message Broker product on the same workstation is not supported.

2. Limitations
   1. Runtime code generation from a flow containing a While node that was recorded using the loop recording functionality

      When a flow contains a While node that was recorded using the loop recording functionality in the host editor, the Service Flow Modeler Technology Preview cannot generate runtime code from that flow for some supported runtime environments:
      

      Runtime environment:	Runtime code can be generated from flow containing While node recorded using the loop recording functionality:
      IBM CICS Integrator Adapter for z/OS	No
      IBM WebSphere Host Access Transformation Services (HATS) 6.0.1 or higher	Yes

   2. Runtime code generation from a flòw containing a LINK3270 node that references a certain type of screen message

      When a screen message has been generated from a BMS mapset that contains the OCCURS parameter, and a flow contains a LINK3270 node that references that screen message, the Service Flow Modeler cannot generate runtime code from that flow.

3. Known problems
   1. Error message: "Workspace in use, choose a different one"

      Closing IBM WebSphere Developer for zSeries^(R) without disconnecting the host editor from the host can cause WebSphere Developer for zSeries not to terminate completely.

      This problem occurs when you are connected to a host in the host editor and you close WebSphere Developer for zSeries by clicking the X in the upper right-hand corner of the workbench. Although WebSphere Developer for zSeries appears to close normally, some WebSphere Developer for zSeries processes are still running (eclipse.exe, javaw.exe). When you restart WebSphere Developer for zSeries and attempt to use the same workspace, WebSphere Developer for zSeries displays the error message "Workspace in use, choose a different one".

      To avoid this problem, before closing WebSphere Developer for zSeries, either close the host editor or disconnect the host editor from the host.

   2. CICS ASP3 abend because of unconnected UNKNOWN terminal of Invoke node

      If an adapter service for the CICS Integrator Adapter for z/OS runtime contains one or more Invoke nodes in which an UNKNOWN terminal is not connected to another node, then a CICS ASP3 abend can occur when you run the adapter service.

      This problem occurs in the following situation:

      • You have a flow that contains one or more Invoke nodes in which an UNKNOWN terminal is not connected to some other node.
      • You create a generation properties file for the flow with a target runtime of CICS Integrator Adapter for z/OS. (The Flow Type can be any flow type: Non Terminal, FEPI, or Link3270 Bridge).
      • You generate runtime code.

      To prevent a CICS ASP3 abend from this cause occurring when you run the resulting adapter service:

      1. Use the flow editor to open the flow from which the runtime code is generated.
      2. In the flow editor, connect any unconnected UNKNOWN terminal of an Invoke node to the flow's Reply node (output node), using one of the following methods:
         • Connect the terminals directly to the Reply node:
           1. Connect any unconnected UNKNOWN terminal of an Invoke node to the Reply node.
           2. When you are finished, all the unconnected UNKNOWN terminals of Invoke nodes are connected to the one Reply node.
         • Connect the terminals to an Assign node that is connected to the Reply node:
           1. Create an Assign node.
           2. Connect any unconnected UNKNOWN terminal of an Invoke node to the input terminal of the new Assign node.
           3. Connect the output terminal of the new Assign node to the Reply node.
           4. For the output terminal of the Assign node, create a one-sided mapping of an error message.
      3. Save the flow and close the host editor.
      4. Re-generate the runtime code.

   3. Missing runtime code for an intermediate Switch node or Invoke node having multiple outputs

      This problem occurs when the Service Flow Modeler generates runtime code for the CICS Integrator Adapter for z/OS runtime from a flow that contains a particular sequence of three consecutive nodes.

      The three consecutive nodes have the following characteristics:

      • The first and second nodes both have multiple output terminals. Only a Switch node or an Invoke node can have multiple output terminals. The following table shows the possible cases and for which cases the problem occurs:
        

        First node having multiple output terminals:	Second node having multiple output terminals:	Does the problem occur?
        Switch node	Switch node	Yes
        Invoke node	Switch node	Yes, but only if the Invoke node does not contain an output mapping.
        Switch node	Invoke node	Yes, but only if the Invoke node does not contain an output mapping.
        Invoke node	Invoke node	Yes, but only if neither Invoke node contains an output mapping.

      • The third node is an Invoke node that contains an input mapping.

      The following illustration shows an example of a sequence of three such nodes:

      

      The resulting problem that occurs when you generate runtime code from a flow like this for the CICS Integrator Adapter for z/OS runtime is that the Service Flow Modeler Technology Preview does not generate runtime code for the second node in the sequence. Usually the COBOL program that is generated compiles without errors. However, at least one paragraph that you would expect to be present in the COBOL program is missing. One way to spot this problem is to look for a gap in the normal sequence of paragraphs. For example, if the following sequence of paragraphs occurs: 1010-, 1030-, 1040-, 1050-, and so on, then the fact that paragraph 1020- is omitted indicates that output code is missing.

      To work around this problem, modify the sequence of three consecutive nodes by creating a different but functionally equivalent sequence of nodes. For example, you can insert an Assign node between the first and second nodes or between the second and third nodes. The Assign node does not have to contain any mapping.

      If the first node or the second node in the sequence is an Invoke node, then you can work around this problem by adding an output mapping (which can be empty) to the first or second node that is an Invoke node:

      1. Right-click on the output terminal of the Invoke node.
      2. Click Open Mappings.
      3. Wait for the mapping editor to open.
      4. You do not have to create a mapping inside the mapping file.
      5. Save the mapping file and close the mapping editor.

   4. Additional requirements with the Startup Transaction Data property

      This note concerns the Startup Transaction Data property. This property appears in the Generation Properties Editor (when you have just created a new generation properties file, or when you are editing an existing generation properties file), on the Node Properties page, in the FEPI Flow Properties group or in the 3270 Bridge Flow Properties group.

      If you are using the Startup Transaction Data property with a terminal (screen-based) application, and you are using the Service Flow Modeler to generate runtime code for the CICS Integrator Adapter for z/OS runtime, then you must do the following in the flow from which you are generating the runtime code:

      • The first Invoke node after the Receive node MUST be for the screen that results from running the CICS Transaction specified in the Startup Transaction Data generation property.
      • This Invoke node MUST also be the first Invoke node that you added to the flow when the flow was created or edited.

      These requirements are necessary to insure that the proper screen recognition code is generated after the transaction is executed.

      You can visually verify that these requirements have been met:

      1. In the flow editor, verify that the first Invoke node after the Receive node is the Invoke node representing the screen that results from running the CICS Transaction specified in the Startup Transaction Data generation property.
      2. While the flow editor is open, in the Outline view, verify that the first node in the tree with an Invoke symbol is the Invoke node representing the screen that results from running the CICS Transaction specified in the Startup Transaction Data generation property.

      In the following example, both requirements are met, and the runtime code will be generated correctly:

      

      In contrast, in the following example, the second requirement is not met. Consequently the runtime code will not be generated correctly and you will get unexpected runtime results:

      

      The following illustration shows the correctly generated code for the first example above:

      

      The next illustration shows the incorrectly generated code for the second example above:

      

   5. Adding an IN message_name REFERENCE message_type statement to the ESQL MODULE for a Switch node

      This subsection describes how to add an IN message_name REFERENCE message_type statement to the ESQL MODULE for a Switch node.

      Before you start to perform the steps below, you should already have the following resources available:

      • A flow (for example, Flow01.seqmap).
        • The flow should be present in the Flows folder of your service flow project.
        • The flow should contain a Switch node to which you want to add an ESQL MODULE containing an IN message_name REFERENCE message_type statement.
      • A message file (for example, myMessages.mxsd) containing a message (for example, msgSwitch01 with a message type of customerName).
        • The message file should be present in the Messages subfolder of the interface definition folder of your service flow project.
        • The message file should contain the message that you want to use in the IN message_name REFERENCE message_type statement.

      To add an IN message_name REFERENCE message_type statement to the ESQL MODULE for a Switch node:

      1. Add an empty expression to the Switch node:
         1. Use the flow editor to open the flow.
         2. In the flow editor, right-click the Switch node, and then click Add Expressions. The Node Properties - Switch window opens.
         3. In the Node Properties - Switch window, add an expression to the Reply Message area:
            • If you have not previously added an expression to the Node Properties for this Switch node, then the Reply Message area of the window contains one expression with the default name Expression.
              1. Select the expression. The line becomes an input area.
              2. Type the name that you want to use for the expression, such as Expression_01.
              3. Click OK to close the Node Properties - Switch window.
            • If you have previously added one or more expressions to the Node Properties for this Switch node, then the Reply Message area of the window displays the names of those expressions.
              1. Click Add to add a new expression.
              2. Type the name that you want to use for the expression, such as Expression_01.
              3. Click OK to close the Node Properties - Switch window.
         4. Leave the flow editor open.
      2. Create an ESQL MODULE for the expression:
         1. In the flow editor, right-click the Switch node, and then click ESQL -> Open ESQL -> Expression_01, where Expression_01 is the name of the expression that you created in Step i above.

            Note: The importance of doing the ESQL -> Open ESQL operation now:

            • You must do the ESQL -> Open ESQL operation at this point, before you do the ESQL -> Add ESQL Message operation in Step iii below.
            • If you do the ESQL -> Add ESQL Message operation in Step iii below without ever having done an ESQL -> Open ESQL operation, then the Service Flow Modeler creates an ESQL MODULE framework for the Switch node but does not add to it the IN message_name REFERENCE message_type statement that you specify. You will have to come back to this step and do the steps in the order described here.
         2. The Service Flow Modeler automatically creates an ESQL MODULE framework for the expression that you created in the previous step. The ESQL editor automatically opens the ESQL file and displays the contents:

            

         3. In the ESQL editor, type Ctrl-S to save the contents of the ESQL file.

            Note: The importance of typing Ctrl-S now:

            • If this is the first message that you are adding to the ESQL MODULE for this Switch node, then you must type Ctrl-S at this point in the procedure. Otherwise, when you perform Step iii below, the IN message_name REFERENCE message_type statement will not be added to the ESQL MODULE.
            • In contrast, if you have already successfully added a message to the ESQL MODULE for this Switch node, and you are now adding an additional message to the same ESQL MODULE, then you do not need to type Ctrl-S at this point in the procedure. You can add an additional message without having to save the ESQL file before each addition.
         4. Leave the ESQL editor open.
      3. Add an IN message_name REFERENCE message_type statement to the ESQL MODULE for the Switch node:
         1. In the flow editor, right-click the Switch node and then click ESQL -> Add ESQL Message -> Expression_01, where Expression_01 is the name of the expression that you created in Step i above. The Add Message Schemas window opens.
         2. In the left pane of the Add Message Schemas window, expand the resources tree and select the message file that you want to use (for example, myMessages.mxsd).
         3. In the right pane of the Add Message Schemas window, select the name of the message that you want to use (for example, msgSwitch01).
         4. Click Finish. The Add Message Schemas window closes.
         5. The Service Flow Modeler automatically adds the IN message_name REFERENCE message_type statement to the ESQL MODULE for the Switch node:

            

      Note: After you have added the first message to the ESQL MODULE for the Switch node, you can add an additional message to the same ESQL MODULE as follows:

      1. Skip Step i above, because you have already created the expression.
      2. Skip Step ii above, because you have already created an ESQL MODULE framework for the Switch node. Optionally, you can type Ctrl-S to save the current contents of the ESQL file.
      3. Perform Step iii above.

   6. Adding an IN message_name REFERENCE message_type statement to the ESQL MODULE for a While node

      This subsection describes how to add an IN message_name REFERENCE message_type statement to the ESQL MODULE for a While node.

      Before you start to perform the steps below, you should already have the following resources available:

      • A flow (for example, Flow01.seqmap).
        • The flow should be present in the Flows folder of your service flow project.
        • The flow should contain a While node to which you want to add an ESQL MODULE containing an IN message_name REFERENCE message_type statement.
      • A message file (for example, myMessages.mxsd) containing a message (for example, msgWhile01 with a message type of customerName).
        • The message file should be present in the Messages subfolder of the interface definition folder of your service flow project.
        • The message file should contain the message that you want to use in the IN message_name REFERENCE message_type statement.

      To add an IN message_name REFERENCE message_type statement to the ESQL MODULE for a While node:

      1. Create an ESQL MODULE for the While node:
         1. In the flow editor, right-click the While node, and then click ESQL -> Open ESQL.

            Note: The importance of doing the ESQL -> Open ESQL operation now:

            • You must do the ESQL -> Open ESQL operation at this point, before you do the ESQL -> Add ESQL Message operation in Step ii below.
            • If you do the ESQL -> Add ESQL Message operation in Step ii below without ever having done an ESQL -> Open ESQL operation, then the Service Flow Modeler creates an ESQL MODULE framework for the While node but does not add to it the IN message_name REFERENCE message_type statement that you specify. You will have to come back to this step and do the steps in the order described here.
         2. The Service Flow Modeler automatically creates an ESQL MODULE framework for the While node. The ESQL editor automatically opens the ESQL file and displays the contents:

            

         3. In the ESQL editor, type Ctrl-S to save the contents of the ESQL file.

            Note: The importance of typing Ctrl-S now:

            • If this is the first message that you are adding to the ESQL MODULE for this While node, then you must type Ctrl-S at this point in the procedure. Otherwise, when you perform Step ii below, the IN message_name REFERENCE message_type statement will not be added to the ESQL MODULE.
            • In contrast, if you have already successfully added a message to the ESQL MODULE for this While node, and you are now adding an additional message to the same ESQL MODULE, then you do not need to type Ctrl-S at this point in the procedure. You can add an additional message without having to save the ESQL file before each addition.
         4. Leave the ESQL editor open.
      2. Add an IN message_name REFERENCE message_type statement to the ESQL MODULE for the While node:
         1. In the flow editor, right-click the While node and then click ESQL -> Add ESQL Message. Add Message Schemas window opens.
         2. In the left pane of the Add Message Schemas window, expand the resources tree and select the message file that you want to use (for example, myMessages.mxsd).
         3. In the right pane of the Add Message Schemas window, select the name of the message that you want to use (for example, msgWhile01).
         4. Click Finish. The Add Message Schemas window closes.
         5. The Service Flow Modeler automatically adds the IN message_name REFERENCE message_type statement to the ESQL MODULE for the While node:

            

      Note: After you have added the first message to the ESQL MODULE for the While node, you can add an additional message to the same ESQL MODULE as follows:

      1. Skip Step i above, because you have already created an ESQL MODULE framework for the While node. Optionally, you can type Ctrl-S to save the current contents of the ESQL file.
      2. Perform Step ii above.

4. Authoring issues
   1. Creating reliable screen descriptions

      A reliable screen description is one that matches the particular application screen that you want it to match, and that does not mistakenly match any other application screen that can occur at the same point in the host application.

      In general, for each application screen that occurs in a terminal application (this can be referred to as the "original application screen"), only a few application screens, or frequently only one application screen, can occur next (these can be referred to as the "possible next application screens").

      In the Next Screens subcomponent of the screen interaction for the original application screen, you should verify that a screen description is included for each possible next application screen.

      If more than one possible next application screen can occur following the original application screen, you should modify, if necessary, the screen description of each of the possible next application screens, so that each screen description accurately and unambiguously matches the correct possible next application screen.

      In all cases, it is recommended that you use only String descriptors or Field Pattern descriptors in screen descriptions. (For a flow from which you generate runtime code for the CICS Integrator Adapter for z/OS runtime, you must use only String descriptors or Field Pattern descriptors in screen descriptions.)

      For each screen description, a single String descriptor or a single Field Pattern descriptor might be sufficient, depending on how similar the possible next application screens are to one another.

      Whenever you create a default screen description (whether by using the Capture Screen icon in the host editor, or by automatically capturing a screen during screen operations recording or flow recording, or by importing a BMS map or a HATS screen), the default screen description contains three default descriptors: a Number of Fields descriptor, a Number of Input Fields descriptor, and a Fields Checksum descriptor. This default screen description is created for the purpose of getting you started in the host editor environment. It is recommended that you modify every default screen description as follows so that it is no longer a default screen description:

      1. Delete any descriptor that is not a String descriptor or a Field Pattern descriptor. (Delete the default descriptors).
      2. Add one or more String descriptors or Field Pattern descriptors to the screen description. A single brief String descriptor or Field Pattern descriptor is sufficient, if it provides enough information to differentiate one possible next application screen from all the other possible next application screens that can occur at that point in the application.

      Also, during flow recording or screen operations recording, for each application screen, you should verify that the correct screen description is recognized before you enter any input.

   2. Waiting for the application screen to settle during recording

      When you are doing flow recording in the host editor, for each application screen that is displayed, you should allow the application screen to settle (to be completely updated by the host application) before you enter an AID key (such as Enter, Clear, PF1, and so on) that causes a transition to the next application screen.

      Allowing the screen to settle is particularly important when the current application screen does not contain any input fields for you to type text into.

      Failing to allow the screen to settle can cause the recorded flow to be invalid.

      For some session types, the host editor warns you when you might have entered an AID key without first allowing the screen to settle:

      

   3. Handling an application screen where the same input action can result in more than one different resulting application screen.

      Sometimes in a terminal application an application screen exists (this can be referred to as the "original application screen") for which the same input action (for example, PF8) can result in the next application screen being any one of several different possible application screens, each of which you want to recognize and handle differently (these can be referred to as the "possible next application screens").

      What is unusual about this scenario is that the same input action can result in one or more different next application screens.

      You should deal with this type of scenario exactly as you would deal with the more usual scenario in which a different input action results in a different next application screen. That is:

      1. For each of the possible next application screens:
         1. Create a unique screen description, so that the particular possible application screen can be recognized.
         2. Create an appropriate screen interaction that references the unique screen description created in the previous step.
      2. Verify that the names of the screen descriptions for all the possible next application screens are included in the Next Screens list of a screen interaction for the original application screen.

      For example, suppose that the original application screen is a Utilities application screen in which the user can run a utility by typing the name of utility and pressing Enter. Depending on the return code from the utility, the possible next application screens include the following:

      • A "success" application screen:
        • This application screen contains the word "Success" at a particular location.
        • When this application screen occurs, you want to launch a second utility.
      • A "failure" application screen:
        • This application screen contains the word "Failure" at a particular location.
        • When this application screen occurs, you want to navigate back one level up the menu hierarchy to a previous application screen.

      To manage this sequence of application screens:

      1. Create a screen description for each of the possible next application screens. For example:
         1. Create a screen description for the "success" application screen and name the screen description scUtility01Success.
         2. Create a screen description for the "failure" application screen and name the screen description scUtility01Fail.
      2. In a flow recording, record a screen interaction to handle each of the possible next application screens. For example:
         1. For the "success" application screen:
            1. Start recording.
            2. Navigate to the "success" application screen.
            3. Verify that the host editor recognizes the correct screen description (scUtility01Success).
            4. Record the screen interaction that you want use:
               1. Type the name of the second utility in the appropriate input field.
               2. Press the Enter key.
         2. For the "failure" application screen, use the same method to create an appropriate screen interaction.
      3. Verify that the Next Screens list in the screen operation for the original application screen (the Utilities application screen) includes the names of all the screen descriptions for the possible next application screens (scUtility01Success and scUtility01Failure).

      Note: Sequences of application screens that can be handled as loops are a special case of the scenario described in this subsection. You can handle such sequences more easily by creating a loop using the loop recording function during flow recording in the host editor.

5. IBM WebSphere Developer for zSeries^(R)
   1. Invoking WebSphere Developer for zSeries with the -clean option

      This subsection describes how to invoke IBM WebSphere Developer for zSeries with the -clean option. Other subsections in this Readme file can refer to this subsection.

      When the installation of a product onto your workstation results in new or updated code modules being written into the directories where WebSphere Developer for zSeries is installed, you must invoke WebSphere Developer for zSeries once with the -clean option, to cause WebSphere Developer for zSeries to flush its caches and reload them with the latest installed code.

      Note: You need to invoke WebSphere Developer for zSeries with the -clean option only once each time this situation occurs. Thereafter you can invoke WebSphere Developer for zSeries as you normally do, without the -clean option, until the installation of another product requires you to invoke WebSphere Developer for zSeries with the -clean option.

      To invoke WebSphere Developer for zSeries with the -clean option:

      1. Configure a shortcut to run WebSphere Developer for zSeries with the -clean option:
         1. Make a copy of the shortcut that you use to launch WebSphere Developer for zSeries. If you do not use a shortcut to launch WebSphere Developer for zSeries, then create a shortcut to do it.
         2. Name the new shortcut "WebSphere Developer -clean".
         3. Right-click the new shortcut.
         4. Click Properties. The Properties window for the shortcut opens.
         5. Click the Shortcut tab.
         6. In the Target input field, type the -clean option after the name of the .EXE file that launches the WebSphere Developer for zSeries. For example, if the Target input field contains the following command:

            "D:\Program Files\IBM\Rational\SDP\6.0\rationalsdp.exe" 
            

            then type -clean after the command, so that the command now reads:

            "D:\Program Files\IBM\Rational\SDP\6.0\rationalsdp.exe" -clean
            

         7. Click OK to close the Properties window.
      2. Use the new shortcut to launch WebSphere Developer for zSeries:
         1. Run the "WebSphere Developer -clean" shortcut.
         2. Wait for WebSphere Developer for zSeries to open completely.

            Note: WebSphere Developer for zSeries takes much longer to open when it invoked with the -clean option.

         3. Close WebSphere Developer for zSeries in the normal way.
      3. You have now finished invoking WebSphere Developer for zSeries with the -clean option.
         • You can now launch WebSphere Developer for zSeries as you normally do, without using the "WebSphere Developer -clean" shortcut.
         • Save the "WebSphere Developer -clean" shortcut, in case you want to again invoke WebSphere Developer for zSeries with the -clean option at some time in the future.

Runtime environments

1. General
   1. Supported runtime environments

      You can use the Service Flow Modeler Technology Preview to generate runtime code for the following IBM runtime environments:
      

      IBM runtime environment:	IBM product required for runtime environment:
      IBM CICS Integrator Adapter for z/OS	IBM CICS Transaction Server version 3.1 or higher
      IBM WebSphere Host Access Transformation Services (HATS) 6.0.1 or higher	IBM WebSphere Application Server

2. IBM CICS 3270 Integrator Adapter for z/OS
   1. Invocation of Web services through SOAP not supported with CICS TS 3.1

      If you use the Service Flow Modeler Technology Preview to generate an adapter service, and you  then create a Web service from the adapter service, you cannot invoke the Web service via SOAP on CICS TS 3.1.

3. IBM WebSphere Host Access Transformation Services (HATS) runtime environment
   1. HATS 6.0.1 required

      If you want to use the Service Flow Modeler Technology Preview to generate HATS macros and deploy them to the HATS studio, you must have HATS version 6.0.1 or higher installed on the target workstation.

   2. Invoke WebSphere Developer for zSeries with -clean option after installing HATS on top of the Service Flow Modeler Technology Preview

      If you install the Service Flow Modeler Technology Preview, and you subsequently install HATS 6.0.1 on the same workstation, you must invoke WebSphere Developer for zSeries with the -clean option to ensure that the Service Flow Modeler Technology Preview perspective is available (see Invoking WebSphere Developer for zSeries with the -clean option).

   3. On Windows^(R) 2000 Server or Windows 2003 Server, if HATS is installed on top of the Service Flow Modeler Technology Preview, you may need to re-enable the SWT Host Access Beans 1.0.1 feature in the WebSphere Developer for zSeries workbench before you can open the Service Flow Modeler perspective or the HATS perspective

      If your workstation is running Microsoft Windows 2000 Server or Windows 2003 Server, and you install HATS on the workstation after installing the Service Flow Modeler Technology Preview, the HATS installation may disable the IBM SWT Host Access Beans 1.0.1 feature, causing the Service Flow Modeler perspective and the HATS perspective to become unavailable.

      To re-enable the perspectives:

      1. On the WebSphere Developer for zSeries workbench's menu bar, click Help -> Software Updates -> Manage Configuration. The Product Configuration window opens.
      2. In the left pane of the Product Configuration window, find the entry for IBM SWT Host Access Beans 1.0.1 and right-click it.
      3. Click Enable.
      4. Close the Product Configuration window.
      5. Restart the WebSphere Developer for zSeries workbench.

National Language Support

1. General
   1. Service Flow Modeler Technology Preview does not include translated versions of user interface and documentation

      In the Service Flow Modeler Technology Preview the user interface and documentation are in English only.

2. DBCS languages
   1. Support for DBCS languages is not enabled

      The Service Flow Modeler Technology Preview is not enabled for support of DBCS languages.

3. Bi-directional languages
   1. Support for bi-directional languages is not enabled

      The Service Flow Modeler Technology Preview is not enabled for support of bi-directional languages such as Arabic and Hebrew.