Release notes, known problems, limitations, and workarounds affecting service flow (SFM) projects

A Web service generated from a service flow project cannot call itself (recursive call)

A Web service generated from a service flow project cannot call itself, either directly or indirectly. In general, the service flow project tools do not allow you to create a recursive invocation of a flow, that is, a flow invoking itself, either directly or through intermediate calls.

However, the service flow project tools currently do not detect the following type of recursion:
  • You generate a Web service (for example, WS01) from a service flow project.
  • The generated Web service (WS01) invokes some other Web service (for example, WS02). (By the way, in the Enterprise Service Tools, WS02 is termed an "outbound Web service", because it is external to the Web service that invokes it.)
  • The invoked Web service (WS02) in turn invokes the original Web service (WS01).

In this situation: The flow editor does not detect the recursion when you create it and does not display an error message. You can successfully generate runtime code for the CICS Service Flow Runtime and deploy the Web service (WS01). When you run the Web service (WS01), the invocation to the second Web service (WS02) is successful. However, the recursive invocation (from WS02 back to WS01) fails.

Screen messages are not easily replaced

Problem: If you accidentally delete screen message files and attempt to re-import or re-capture screens to replace them, references to the messages in those files may remain broken. This is because for each screen message, a unique identifier is generated, and this unique identifier is used to identify the screen messages in other files.

Workaround: Back up your projects often. If you accidentally delete screen message files and do not wish to re-model your flows, bring screen messages back by importing the backed up versions of the files rather than re-importing or re-capturing your screens.

A limitation on imported source code with a usage clause of POINTER

Problem: Importing COBOL or PL/I source code data structures containing fields with a usage type of POINTER will create a message with a corresponding field of type hexBinary. This will cause the Generate Runtime Code wizard to fail.

Workaround: Edit the message in the Message Editor. On the Advanced tab of the editor, change the field's type from hexBinary to int. This change enables the generation to complete successfully.

A limitation on a flow with a connection wired back onto itself

Problem: The flow editor does not prevent you from adding connections that wire the execution path of a flow back onto itself (at an earlier point in the flow's execution path). This situation may not cause errors when you generate runtime code. However it is very likely to lead to errors during runtime processing.

Workaround: When you want part of a flow to be iterated multiple times so long as a certain condition is true, use a While node (see the topic "Creating a loop" in the Enterprise Service Tools documentation).

Conflicting message and field names cause compile error

Problem: When you model a flow, and a field of one message has the same name as another message, the generated COBOL code may not compile, reporting a IGYPS0037 error, due to the naming conflict. For example, if the flow references (1) a message called 'X' with a field called 'Y' and (2) a message called 'Y', when the generated code refers to item 'Y' the COBOL compiler will not know whether the reference is to the message 'Y' or the field 'Y OF X'.

Workaround: Refactor either the message or the field to resolve the name conflict. In the EST Project Explorer, select one of the items with the duplicate names. Open the context menu and choose Rename.

Importing a COBOL copy book file fails when the path or file name contains non-English characters

Problem: If you attempt to import a COBOL copy book file, and the file path or the file name contains non-English characters, then the import fails.

Workaround: Rename the COBOL copy book file so that the name contains only English characters. Locate the file in a directory whose path contains only English characters.

Importing a PL/I include file fails when the path or file name contains non-English characters

Problem: If you attempt to import a PL/I include file, and the file path or the file name contains non-English characters, then the import fails.

Workaround: Rename the PL/I include file so that the name contains only English characters. Locate the file in a directory whose path contains only English characters.