Table of Contents

Search

  1. Preface
  2. Overview, Downloading, and Installing
  3. Administration API
  4. Identity Service API
  5. Screenflow Programming and SDK
  6. ActiveVOS WSHT API
  7. Embedding Request Forms in Standalone Web Pages
  8. XML-JSON for Process Central

7. APIs, SDKs, and Services

7. APIs, SDKs, and Services

Fault Handling

Fault Handling

A guide's developer should not have to think about fault handling when building service call steps. Your process can handle two fault types by using the
automatedStep
operation's fault messages in callback responses. You do not need to add process or scope fault handlers to your process. Use a
Reply with Fault
for fault handling. An internal Process Designer service catches the fault and presents an error to the user.
The two fault messages are:
  • automatedStepValidationFault
    with a fault name of
    invalidData
    You can add programming logic to your BPEL process to check for invalid data items in the request message. You can also create a callback response containing an error message that indicates missing or invalid data. Doing this lets the user correct the request data and resubmit it. Essentially, an internal service catches the fault and presents an error screen to the user. See the example below of using the reply with fault handler. A sample fault message looks like this:
    <xsd1:invalidData xmlns:xsd1="http://schemas.active-endpoints.com/ appmodules/screenflow/2010/10/avosScreenflow.xsd"> <xsd1:
    field name=
    "Customer Id"
    reason
    ="Incorrect number of digits"
    required
    ="true"/> </xsd1:invalidData>
    where
    • field name
      : The data field
    • reason
      : The string describing the problem
    • required
      : A Boolean indicating true for required and false for optional. If the field is required, the user is not allowed to advance to the next screen without valid data entered.
  • automatedStepFault
    with a fault name of
    fault
    .
    This fault is similar to the invalid data fault, but allows you to create an error message that tells the user to make corrections; for example, the user cannot schedule a Saturday delivery to the address entered. This fault can also handle cases where a new version of the BPEL process is deployed with new required fields after a guide is published.
    A sample fault message looks like the following:
    <xsd1:screenFlowFaultResponse xmlns:xsd1="http://schemas.active-endpoints.com/ appmodules/screenflow/2010/10/avosScreenflow.xsd"> <xsd1:reason>string</xsd1:reason> </xsd1:screenFlowFaultResponse>
    The following illustration shows an example of creating a reply with fault activity to check for invalid data. The link to the callback reply contains a transition condition that checks for invalid data.