11g Release 5 (11.1.5)
Part Number E20388-04
Contents
Contact
Us
|
Oracle® Fusion
Applications CRM Extensibility Guide 11g Release 5 (11.1.5) Part Number E20388-04 |
Contents |
Contact Us |
 Previous |
 Next |
This chapter contains the following:
Object Workflows and Oracle Fusion CRM Application Composer: How They Work Together
Object Workflows and Field Updates: How They Work Together
Object Workflows and E-Mail Notification: How They Work Together
Object Workflows and Task Creation: How They Work Together
Object Workflows and Outbound Message: How They Work Together
Creating Object-Specific Web Services: Explained
FAQs for Creating Object Workflows
The object workflows represent orchestrated business processes that are invoked based on the conditions that you define for triggering such processes. You must have administrative privileges to configure object workflows.
To configure an object workflow, select an object for which you want to create a workflow and specify the event point, event condition, and event action for that object.
This figure illustrates the create object workflow page.
This figure illustrates the overall process for configuring and triggering object workflows.
Following are some of the common aspects of object workflow definition:
Business Object: A business object or an object can be a standard object delivered with the product or a custom object that you define based on your business need.
Event Point: An event point is associated with an object and is an instance when an event occurs. Event points are of the following types:
When a record is created.
When a record is updated.
Event Condition: An event condition is a trigger for invoking object workflows. It is a combination of event point and an expression that supports logical, math operations, or field-value lookups. Defining an expression prevents the triggering of the object workflow each time an update or create event point occurs.
Event Action: An event action determines what action is expected from an object workflow when the conditions set for an object are met.
Event actions are of the following types:
Field Updates.
E-Mail Notification.
Task Creation.
Outbound Message.
You can use the application composer to customize standard business objects delivered as is or create custom business objects based on business needs. You can use both Standard Objects and Custom Objects to define object workflows. How you create and configure these objects determines and enforces that only the data relevant to the object in context is available for selection when defining a workflow. For example, when you define a trigger condition, an expression editor lists only those fields that are relevant to the object that you have selected.
An expression editor supports building logical and math operations, including field lookups that you can optionally use to define trigger condition. Fields in the expression editor are populated based on the object for which you are defining a workflow. The expression editor displays a warning if your expression contains an invalid attribute name. However, you must confirm whether the attribute name is actually invalid. If an attribute exists which was created at runtime, then you can safely ignore the warning.
This figure illustrates the expression editor using which you can define groovy conditions for object workflows.
Use the expression editor to write Groovy-based application logic that determines when an object workflow is triggered. Some examples of the raise conditions you can use include the following:
Example 1:
Status=='IN_PROGRESS' && BudgetAvailableDate==Today() + 30
Example 2:
if (isAttributeChanged('PrimaryContactPartyName') &&
PrimaryContactPartyName =='Business World') return true; else return false;
Example 3:
WinProb>10 || WinProb<50
In addition, keep these points in mind when using the expression editor to build raise conditions:
Ensure that you return a valid boolean as part of your raise condition. Returning a non-boolean value could lead to runtime errors.
Use return true or return false to explicitly return
the boolean value and code indentation when the evaluation logic is
complex, to minimize risk of runtime errors.
For lookup values, use the lookup code instead of the display value.
Use <, >, == for comparison.
For the event point When a record is updated, avoid redundant
calls of the actions by always specifying which field change should
trigger the object workflow, using the function isAttributeChanged.
Be aware of Groovy-type coercion, if you are not returning an explicit boolean value.
Use the logging capability to debug your condition and review the generated log by selecting Runtime Messages in the Common Setup pane.
For more information, see the Developer's Guide to Scripting in Oracle Fusion CRM Application Composer on My Oracle Support at https://support.oracle.com.
While defining an event action, you can optionally set an execution schedule that governs when an event action should happen. Else, the event actions are run immediately. When multiple event actions are configured, the Field Updates happen first before any other event action is triggered. For event actions other than Field Updates, there is no particular sequence and the event actions are triggered based on whether or how you configure the execution schedule. You can set a time rule for an event action based on whether that event action must occur after or before the triggering of a workflow or the occurrence of a date, and also specify the time duration in Hours, Days, or Weeks. If you schedule an event action for a time in the past, the event action is executed immediately after it is triggered.
This figure illustrates the execution schedule region.
Oracle Fusion CRM Application Composer is a browser-based configuration tool. It is part of the CRM Extensibility Framework that provides a mechanism to extend applications. You must have administrative privileges to work with and configure object workflows using the application composer.
This figure illustrates how the Oracle Fusion CRM Application Composer is used for defining object workflows.
You can use the application composer to customize standard business objects delivered as is or create custom business objects based on business needs. You can use both Standard Objects and Custom Objects to define object workflows. How you create and configure these objects determines and enforces that only the data relevant to the object in context is available for selection when defining a workflow. For example, when you define a trigger condition, an expression editor lists only those fields that are relevant to the object that you have selected.
These examples illustrate the business scenarios where object workflows can be employed to automate business processes.
In a sales division, the management plans to set an automated business process where each new opportunity must have an initial close date set automatically to 90 days from the day of creation of an opportunity. Being an administrator, you must create an object workflow based on management directions.
This figure illustrates an example of an event action triggered as part of object workflow definition.
This figure illustrates the create field updates page that you invoke from object workflow creation page after defining the trigger condition.
To create a workflow, select Opportunity as an object and set the event point as When a record is created. Use the expression
editor to set the event condition as Close
Date is Null.
After defining the trigger condition, select the event action as Field Updates and use the expression editor to set the Close Date to Current Date plus 90 days; hence, when a user creates a new Opportunity in the system, the workflow is automatically activated setting the Close Date to 90 days from the creation date.
In a sales division, the management plans to set a business process that when an opportunity is updated whose close date is current or past and the status is open, a reminder e-mail should be sent to specified recipients and the close date should be extended by 15 days. Being an administrator, you must create an object workflow based on management directions.
This figure illustrates an example of multiple event actions triggered as part of object workflow definition.
This figure illustrates the create e-mail notification page that you invoke from object workflow creation page after defining the trigger condition.
To create an object workflow with two event actions, select Opportunity object and set the event point as When a record is updated. Use the expression editor to set an event condition as Close Date is less than or equal to Current Date and Status is Open.
After defining the trigger condition, select an event action as Field Updates and use the expression editor to define an expression to set the Close Date to an additional 15 days. Create another event action as E-Mail Notification and specify the Recipients; hence, when an Opportunity is updated, the workflow checks the event conditions. If the conditions are met, an e-mail is sent to the specified recipients and the Close Date is extended by 15 days.
As part of object workflow definition, you can configure automatic field updates by specifying what fields you want to update and the value to apply to those fields. You must have administrative privileges to configure object workflows for field updates.
This figure illustrates how the field updates are configured and invoked.
To define an object workflow for Field Updates, select an Object and provide a meaningful Name for the workflow. Define the event trigger conditions and select Field Updates as the event action to configure and update one or more fields for the selected object.
For configuring Field Updates event action, define the Name and Description for the field update action and optionally set the Execution Schedule for triggering such updates. When you select a field to update, the options on the page dynamically change for configuring field update actions depending on the field type. For example, if you select a field of type Date, a Date Picker appears.
In case of static choice list, the list of field values can either be in an alphabetical order or in the display sequence such as High, Medium, or Low, as defined. For updating static fields that have a display sequence, you can specify whether the field is to be populated with next value in list or populated with previous value in list during field updates. For example, assuming a display sequence of High, Medium, or Low, you can change High to Medium (populate with next value) or Low to Medium (populate with previous value) during field updates. However, if the current value is Low, and the event action has been configured using Populate with next value in the list, the field is not updated when the action is executed, because Low is already the last value in the sequence. Use Update More Fields option to select additional fields for an update.
The field-updates event action acts on the same object that raises the event. For example, when you create an Opportunity object and do not specify the Close Date, you can define a Field Update action that sets the Close Date automatically to 90 days after the creation date.
While defining an event action, you can optionally set an execution schedule that governs when an event action should happen. Else, the event actions are run immediately. When multiple event actions are configured, the Field Updates happen first before any other event action is triggered. For event actions other than Field Updates, there is no particular sequence and the event actions are triggered based on whether or how you configure the execution schedule. You can set a time rule for an event action based on whether that event action must occur after or before the triggering of a workflow or the occurrence of a date, and also specify the time duration in Hours, Days, or Weeks. If you schedule an event action for a time in the past, the event action is executed immediately after it is triggered.
You can use object workflows to send e-mail communications to the intended recipients as an automated process. You must have administrative privileges to configure object workflows for e-mail notifications.
For example, you can set up a workflow that when the win probability is updated for an opportunity, an e-mail alert is automatically sent out to the resources who are assigned that opportunity along with the required information.
This figure illustrates how e-mail notifications are configured and invoked as part of object workflows.
To define an object workflow for E-Mail Notification, select an Object and provide a meaningful Name and Description for the workflow. Define the event trigger conditions and select E-Mail Notification as the event action to configure one or more notifications for the selected object.
For configuring E-Mail Notification as an event action, provide the Name and Description for the e-mail notification action and optionally set the Execution Schedule for triggering such notifications. Search an e-mail template by using one or more Search parameters such as full or partial Name, Description, or Subject, or by specifying whether the template is Active. Select a template to use and provide the information that you require in the e-mail alert. The fields that you select for an e-mail alert are populated during runtime.
Use the Recipient Types list box to select and send e-mail notifications to a list of resources or enter Specific e-mail addresses separated by a comma. Depending on the Recipient Type, you can configure e-mail notifications for relative users, roles, or specific users. A user can be, for example, creator of the object for which event action is defined, the person who last updated the record, direct or indirect subordinates, or sales resources working as a team, and so on.
While defining an event action, you can optionally set an execution schedule that governs when an event action should happen. Else, the event actions are run immediately. When multiple event actions are configured, the Field Updates happen first before any other event action is triggered. For event actions other than Field Updates, there is no particular sequence and the event actions are triggered based on whether or how you configure the execution schedule. You can set a time rule for an event action based on whether that event action must occur after or before the triggering of a workflow or the occurrence of a date, and also specify the time duration in Hours, Days, or Weeks. If you schedule an event action for a time in the past, the event action is executed immediately after it is triggered.
Oracle Fusion tasks integrate with BPEL human tasks and are available in the BPEL worklist application. You must have administrative privileges to configure object workflows for Oracle Fusion tasks.
You can configure object workflows to trigger auto-creation and assignment of tasks for an object. You can define tasks event action for only those objects that are configured to support the creation of tasks. For other objects, the tasks option is disabled.
This figure illustrates how tasks are configured and invoked as part of object workflows.
To define an object workflow with a Task Creation event action, select an Object and provide a meaningful Name and Description for the workflow. Define the event trigger conditions and select Task Creation as the event action to configure a task for the selected object.
For configuring Task Creation event action, define the Name and Description for the task action and optionally set the Execution Schedule.
If an object for which you are defining a Task Creation event action contains a customer, that customer is automatically included in the created task.
Use the Task Details to configure a task based on your requirements.
Select a Subject and Description, as appropriate, for your task notification.
Select the Start Date and Due Date for a task. When you select a date, you can also provide logical conditions for these dates, for example, a Due Date must be 30 days after the Start Date.
Select the Owner and Assignees for a task. The values in these lists change depending on the object for which the task is being defined. For example, for an opportunity object, the Assignees list would include the owner, resource team, resource team with different access levels, member functions, and so on.
Selecting the Category to which a task belongs, such as meeting, administration, and so on.
Assigning a Priority to the task. The default priority is 3.
For example, when an opportunity reaches a Close Date and the status is still Open, you can use the Task Creation event action to assign a follow up task to the owner of the opportunity.
While defining an event action, you can optionally set an execution schedule that governs when an event action should happen. Else, the event actions are run immediately. When multiple event actions are configured, the Field Updates happen first before any other event action is triggered. For event actions other than Field Updates, there is no particular sequence and the event actions are triggered based on whether or how you configure the execution schedule. You can set a time rule for an event action based on whether that event action must occur after or before the triggering of a workflow or the occurrence of a date, and also specify the time duration in Hours, Days, or Weeks. If you schedule an event action for a time in the past, the event action is executed immediately after it is triggered.
You can configure an object workflow to send an outbound message to a Web service at a specified endpoint URL. An endpoint URL is an external Web service that shares data with Oracle Fusion CRM.
You must have administrative privileges to configure object workflows.
This figure illustrates how outbound messages are invoked as part of object workflows.
To define an object workflow for outbound messages, select an Object and provide a meaningful Name and Description for the workflow. Define the event trigger conditions and select Outbound Message as the event action to send outbound messages for the selected object.
For configuring an outbound message event action, define the Name and Description for the outbound message action and set the Execution Schedule for triggering the action. Provide the endpoint URL of the external Web service, for example, an endpoint URL can be http://GlobalFusion:7011/OMTestOpportunity/OutboundMessageServiceSoapHttpPort. At runtime, a service data object containing details of the object on which the object workflow is defined is sent to the specified endpoint URL. For example, you can define an object workflow that automatically sends, based on a trigger, an outbound message containing an object like opportunity, lead, or account details from one system to another.
Outbound messages are queued up before they are processed. You can monitor the outbound messages including the history and the queued up messages and their statuses using the Oracle Enterprise Manager.
For more information about Oracle Enterprise Manager, see the Oracle Fusion Middleware Administrator's Guide.
As part of object workflow definition, if a field update event action is also scheduled along with outbound messages event action, the field updates event action is triggered first so that the outbound messages contains the updated data.
While defining an event action, you can optionally set an execution schedule that governs when an event action should happen. Else, the event actions are run immediately. When multiple event actions are configured, the Field Updates happen first before any other event action is triggered. For event actions other than Field Updates, there is no particular sequence and the event actions are triggered based on whether or how you configure the execution schedule. You can set a time rule for an event action based on whether that event action must occur after or before the triggering of a workflow or the occurrence of a date, and also specify the time duration in Hours, Days, or Weeks. If you schedule an event action for a time in the past, the event action is executed immediately after it is triggered.
You can configure an object workflow to send an outbound message to a third-party Web service at a specified endpoint URL. An endpoint URL is an external Web service that receives data with Oracle Fusion Customer Relationship Management (CRM) applications. The third-party Web service must conform to the service WSDL defined by Oracle Fusion CRM.
This topic provides the following:
How to configure a Web service
An example of the OutboundMessageService.wsdl
An example of the OutboundMessageService.xsd
The security policies available
To configure a Web service, you must replace the parameters in the OutboundMessageService.xsd file using the Oracle Fusion Web service instructions.
Navigate to Oracle Enterprise Repository (OER):
For a standard object, search for ADF Service in OER by object name.
For custom objects, search for the generic Web service for all custom objects in the corresponding application, for example, Sales Custom Business Object.
Extract the .xsd files from the live environment URL using the information provided under the service.
Replace the parameters in OutboundMessageService.xsd with the names for the object of your interest.
The parameters are marked in the .xsd file as parameters, $OBJECT_TARGET_NAMESPACE$ and $OBJECT_NAME$.
For more information about Oracle Enterprise Repository, see Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository.
Examples of OutboundMessageService.wsdl and OutboundMessageService.xsd are provided here for reference.
This section includes an example of the OutboundMessageService.wsdl, for your reference.
//Sample OutboundMessageService.wsdl
<wsdl:definitions
name="OutboundMessageService"
targetNamespace="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/"
xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:types="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
>
<wsdl:import namespace="http://xmlns.oracle.com/adf/svc/errors/" location="ServiceException.wsdl"/>
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
schemaLocation="OutboundMessageService.xsd"/>
</schema>
</wsdl:types>
<wsdl:message name="OutboundMessageService_processOutboundMessage">
<wsdl:part name="parameters" element="types:processOutboundMessage"/>
</wsdl:message>
<wsdl:message name="OutboundMessageService_processOutboundMessageResponse">
<wsdl:part name="parameters" element="types:processOutboundMessageResponse"/>
</wsdl:message>
<wsdl:portType name="OutboundMessageService">
<wsdl:documentation/>
<wsdl:operation name="processOutboundMessage">
<wsdl:input message="tns:OutboundMessageService_processOutboundMessage"/>
<wsdl:output message="tns:OutboundMessageService_processOutboundMessageResponse"/>
<wsdl:fault name="ServiceException" message="errors:ServiceException"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="OutboundMessageServiceSoapHttp" type="tns:OutboundMessageService">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="processOutboundMessage">
<soap:operation soapAction="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/processOutboundMessage"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="ServiceException">
<soap:fault name="ServiceException" use="literal" encodingStyle=""/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="OutboundMessageService">
<wsdl:port name="OutboundMessageServiceSoapHttpPort" binding="tns:OutboundMessageServiceSoapHttp">
<soap:address location="http://adc2111013:7101/OMInterface/OutboundMessageService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
This section provides an example of the OutboundMessageService.xsd, for your reference. The parameters are marked in the .xsd file as parameters, $OBJECT_TARGET_NAMESPACE$ and $OBJECT_NAME$.
//Sample: OutboundMessageService.xsd
<schema elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
xmlns:ns0="http://xmlns.oracle.com/adf/svc/errors/" xmlns:ns1="$OBJECT_TARGET_NAMESPACE$"
xmlns:ns2="http://xmlns.oracle.com/adf/svc/types/" xmlns:tns="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://xmlns.oracle.com/adf/svc/types/" schemaLocation="BC4JService.xsd"/>
<import namespace="$OBJECT_TARGET_NAMESPACE$" schemaLocation="$OBJECT_NAME$.xsd"/>
<import namespace="http://xmlns.oracle.com/adf/svc/errors/" schemaLocation="ServiceException.xsd"/>
<element name="processOutboundMessage">
<complexType>
<sequence>
<element name="object" type="ns1:$OBJECT_NAME$"/>
</sequence>
</complexType>
</element>
<element name="processOutboundMessageResponse">
<complexType>
<sequence/>
</complexType>
</element>
</schema>
The object workflow outbound messages can use either an authentication-only client side security policy or a transport-level security policy that can protect the message during transfer. The default authentication-only policy used by object workflow outbound message is oracle/wss10_saml_token_client_policy, which includes security assertion markup language (SAML) tokens in outbound simple object access protocol (SOAP) request messages. This policy should only be used when the target web service is located within a secure network segment. The corresponding service can use any compatible service policy, such as oracle/wss10_saml_token_service_policy or oracle/wss_saml_or_username_token_service. You must protect the message when the service is outside your firewalls. When protected, the outbound message uses oracle/wss_username_token_over_ssl_client_policy with one-way SSL enabled by default. The corresponding service must use the compatible oracle/wss_saml_or_username_token_over_ssl_service_policy service policy.
For more information on basic administration involving deployment, configuration, and management of Web services, see part II of the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
You can create, manage, and use e-mail templates for configuring e-mail notifications as part of object workflows. E-mail templates define the layout of the e-mails, which ensures that e-mail notifications triggered by the same type of business event for a specific object have a consistent look and feel. You must have administrative privileges to define e-mail templates.
A template is created for a particular type of object and can be used only with that object when defining e-mail notifications. You can compose e-mail templates using the Oracle Fusion CRM Application Composer user interface or use any e-mail editor to create a template and then upload the template using the user interface. You can use e-mail templates, for example, for including your company letterhead in outbound e-mail communications.
You can Search an e-mail template using either or all of the search parameters such as full or partial Name of the template, the Object to which the template is associated, and whether the template is Active.
Managing e-mail templates include tasks that enable you to Search, View, Duplicate, Create, Edit, or Delete a template.
Options available for managing e-mail templates include:
Viewing the existing e-mail templates and customizing views.
Filtering or querying existing templates including partial search using wildcard.
Editing an existing template or creating a duplicate.
Note
You cannot change the object for which a template is defined.
Creating and configuring a new template.
Detaching the listed templates for a full-page view.
Viewing which templates are Active.
Note
Only an Active template can be used for object workflow definition. Saving does not automatically make the template Active.
You can define a template using the formatting features as available in any HTML based e-mail client. Templates are automatically converted to plain text for users who cannot view HTML e-mails. Advanced HTML users can edit the templates using the Source Code Editing Mode where the tags are set to visible. These advanced users can copy and edit the source code in any HTML editor, and then paste the edited code back to Oracle Fusion. While defining an e-mail template, the fields you select and embed in a template are specific to the selected object. The fields are populated with values at runtime.
Options available for configuring e-mail templates include:
Specifying Name and Description for the template.
Attaching artifacts relevant to the e-mail template. Attachments are included in every e-mail that uses the template having an attachment. You can also send attachments as links to avoid crowding the Inbox of the recipients. An attachment can be a file on a local computer or a shared file in a repository.
Note
File attachments cannot exceed 10 MB.
Specifying whether an e-mail template is Active.
Note
You can use only the Active templates when creating object workflows for e-mail notifications.
Inserting the Fields or Functions, as applicable. You can use Functions to insert Date, Current date and time, or a Hyperlink to record, which triggers an e-mail notification. You can also Browse and then insert the content of a local file in the body of the e-mail template.
Performing basic formatting such as font format, character format, paragraph alignment, bullets and numbering, and so on as in any HTML based e-mail client.
E-mail templates can become invalid if the corresponding template file of the e-mail template cannot be found in the file repository. This can happen if the template file was migrated elsewhere, or deleted accidentally. Contact your application administrator to attempt to recover the template file by reviewing your file repository setup. If the file cannot be recovered, then you can delete the e-mail template and create a new one.
|
Previous |
Next |
 Copyright © 2011-2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
Contents |
Contact Us |