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

2. Designer

2. Designer

Migration Service

Migration Service

The migration service allows fine grain control over migrating running process instances to a newer (or different) version of a process definition. The simplest way to migrate running processes is to specify this choice in the Process Deployment Descriptor of the newer version being deployed, on the General Deployment Options page.
However, if the newer process version has significant changes, such as new activities, variables, or participants, you can create a migration service to test the migration, by selecting one or a few process instances to migrate. Then analyze the results on the Active Process Details page of the server. If errors occur, a process is suspended and errors are reported in the server log. Please note that Process Server does not validate changes to incoming and outgoing message structures between the existing plan and the new plan.
Another use case for a migration service is to have fine grain control over migration. For example, you don't have to migrate instances to the online version of the same process definition. You can migrate to any other process definition that is on the server. And you can pinpoint only those running process instances that you want to migrate.
The process you create for handling migration uses the Migrate system service that has two operations that you must use in order:
  • Create Map operation
    This operation takes as input the Plan Id of the process definition that process instances are running against. Each Plan Id on the server is unique and is a property of each version of a process definition. All process instances run against a Plan Id.
    The create map operation returns a migration map XML document as a string. The map contains the migration structure between plans, which describes the transformation of the activities, links, and variables from one process definition to the other.
  • Migrate operation
    This operation takes as input the migration map and the process id (pid) of the running process instance to migrate.
    The migrate operation returns the XML document that contain list of migration warnings (if any) and the backup process Id. By default, the process instance is migrated to the Plan Id of the online version of the same process definition, but you can specify any Plan Id on the server.


Updated March 30, 2020