Table of Contents

Search

  1. Preface
  2. Welcome to Informatica Process Developer
  3. Using Guide Developer for the First Time
  4. Getting Started with Informatica Process Developer
  5. About Interfaces Service References and Local WSDL
  6. Planning Your BPEL Process
  7. Participants
  8. Implementing a BPMN Task or Event in BPEL
  9. Implementing a BPMN Gateway or Control Flow
  10. Using Variables
  11. Attachments
  12. Using Links
  13. Data Manipulation
  14. Compensation
  15. Correlation
  16. What is Correlation
  17. What is a Correlation Set
  18. Creating Message Properties and Property Aliases
  19. Adding a Correlation Set
  20. Deleting a Correlation Set
  21. Adding Correlations to an Activity
  22. Rules for Declaring and Using Correlation Sets
  23. Correlation Sets and Engine-Managed Correlation
  24. Event Handling
  25. Fault Handling
  26. Simulating and Debugging
  27. Deploying Your Processes
  28. BPEL Unit Testing
  29. Creating POJO and XQuery Custom Functions
  30. Custom Service Interactions
  31. Process Exception Management
  32. Creating Reports for Process Server and Central
  33. Business Event Processing
  34. Process Central Forms and Configuration
  35. Building a Process with a System Service
  36. Human Tasks
  37. BPEL Faults and Reports

Designer

Designer

Retry-Policy Service

Retry-Policy Service

At times an endpoint may not reply when it is invoked in a BPEL process. In normal circumstances, the invoke faults. To avoid this, you can attach a policy to the endpoint reference in the PDD file to indicate that additional retry attempts are allowed at a specified interval for the endpoint. This technique is described in
Process Developer > Part IV: Testing and Deployment > Process Deployment > Endpoint Reference Addressing Considerations
.
Alternately, you can name a service in the policy section of the PDD file whose job it is to provide a retry interval, that you may want to calculate dynamically, and do additional work programmatically. The service could also specify an alternate endpoint to try when the invoke is faulting or suspended.
This service, which is a retry-policy service, is a process you can create and that the Process Server instantiates when an invoke activity is faulting (or suspended). The retry-policy process must be based on a WSDL named
retryCheck.wsdl
.
In essence, the WSDL defines the
retryCheck
operation that receives information from the server regarding the fault name, process Id, and other details of the faulting invoke activity. The process you write is instantiated when the invoke activity faults (or can be suspended), and it receives an input message identifying details of the fault.

0 COMMENTS

We’d like to hear from you!