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

My Role Binding Service Name and Allowed Roles Options

My Role Binding Service Name and Allowed Roles Options

A Process Deployment Descriptor (.pdd) file describes the information required for a process to execute in the ActiveVOS server environment. When creating the .pdd file, you must select a binding style and service name for each service partner link of my_role type.
During the creation of the Process Deployment Descriptor file, you must select a binding style and service name for each service partner link of my_role type.
The binding styles are the standard SOAP styles of RPC (remote procedure call) and Document, and there are custom styles called Unpublished and Policy Driven.
Select the style that is appropriate for the simple, schema, or complex message variable manipulated by your service's operation:
  • A
    Document Literal
    invocation means the entire SOAP message consists simply of a single entity that is an XML document. This invocation is equivalent to a binding style of document/literal.
  • An
    RPC Encoded
    invocation means that the body of a SOAP request has an outer element that matches the operation name and contains inner elements each of which maps to a parameter of the operation.
  • An
    RPC Literal
    invocation means that the body of a SOAP request has an outer element that matches the operation name and each inner part points to a schema type definition that describes the content of that part. RPC is the binding style and
    literal
    is the
    use
    .
  • An
    Unpublished
    invocation bypasses the standard invocation framework. The primary reason for deploying with the unpublished binding is to take advantage of facilities offered by the application server with regard to securing or managing the Web service. Instead of using the built-in mechanism provided by Process Developer for service publication, you can control the publication of your services through an invocation such as J2EE for Web Services (WS4EE). Also, Process Developer system services are specified as unpublished.
  • A
    Policy Driven
    invocation means that the specific facilities used for handling SOAP requests are determined at deployment by the policy assertions attached to the
    myRole
    endpoint. For example, services that support WS-Reliable Messaging protocol can select Policy Driven as the binding style and include an WS-Reliable Messaging policy. At deployment, if the service cannot determine the binding style from the policy assertions, an error is thrown.
  • The
    Service Name
    is the name of the endpoint that Process Server creates for the BPEL process. This name can match the address in the binding section of the WSDL file, or any name desired. By default, the service name is based on the port type associated the partner link.
  • Allowed Roles
    is optional and specifies one or more security roles that an authenticated user must have in order to communicate with the BPEL process. If the application server is not configured with security. the allowed roles field is ignored. Refer to your application server documentation on how to secure individual web applications.
    You must complete this field when deploying a process to Informatica Cloud. if you do not specify at least one role, no one will be able to access the process.
You can also add policy assertions to the my role partner link, as described in Adding Policy Assertions.


Updated March 30, 2020