Business Processes and Rules: Siebel eBusiness Application Integration Volume IV > Data Mapping Using Scripts >

Exception Handling Considerations

There are three categories of errors you might encounter in the data transformation area of your integration. These categories are:

• Siebel errors. Errors signaled by the built-in facilities that execute a map; for example, run-time Siebel eScript errors, business service invocation errors, BusComp errors, and errors in the data transformation functions.
  • Siebel errors are fatal, terminating execution of the map immediately.
  • The business service returns an error code other than OK. No specific error code is guaranteed, and they are not intended for workflow branching. Workflow processes can branch on the indication of an error occurrence, but not on a specific code.
  • The CSSService error stack will contain useful error information. In particular, data transformation function errors will generate error stacks describing the particular error.
• User errors. Errors signaled in custom maps using the EAIRaiseErrorCode call. These are similar to Siebel Framework errors, except that the map developer selects the error code and uses them for workflow branching.
  • User errors are fatal, terminating execution of the map immediately.
  • The service returns the error code specified in the call to EAIRaiseErrorCode. Your workflow can branch on this code.
  • Available error codes are those in the Workflow generic error set.
  • You specify the entire error text for these generic errors in the call to EAIRaiseErrorCode.
  • You can use the function EAIRaiseError to raise an error without specifying a particular error code.
• Map status flags. The map developer can use the SetArgument method to set custom status information in the output property set. For example, you can use the SetArgument method to indicate that a required field is missing. This can be used for workflow branching, if desired. This mechanism is independent of calls made to EAIRaiseError.