Oracle® Fusion
Applications Sales Implementation Guide 11g Release 5 (11.1.5) Part Number E20373-05 |
Contents |
Contact Us |
Previous |
Next |
This chapter contains the following:
Before using the Oracle Fusion CRM for Microsoft Outlook application, several setup tasks must be performed. Some of these are Fusion-specific tasks that are done by the environment hosting team or the customer implementation team. Other tasks are related to setting up the users' computers to use the application, including the install and initialization of the extensions to Microsoft Outlook (Outlook). These tasks are described in more detail in the sections that follow.
For information on supported software versions, see the related topic, Supported Software for Oracle Fusion CRM for Microsoft Outlook: Explained.
At a high level, the following are the Oracle Fusion-specific setup tasks involved in implementing CRM for Microsoft Outlook:
Required: Install Fusion CRM, including the CRM for Microsoft Outlook application.
Required: Perform Fusion setup tasks for Oracle Fusion Common Components, Oracle Fusion Customer Center, Oracle Fusion Sales, and Oracle Fusion Marketing.
Optional: Perform customization and security changes for CRM for Microsoft Outlook, after initial setup.
At a high level, the following are the setup tasks required for each computer that will run CRM for Microsoft Outlook:
Required: If not already present, install Microsoft .NET framework version 3.5 SP1 (or later).
Required: Download and install the Fusion CRM server certificate.
Required: Download and run the CRM for Microsoft Outlook installer.
Required: Complete First Run Assistant to set up application options and perform initial synchronization to get Outlook configuration and user data from the Fusion CRM application.
The overall process flow for implementing CRM for Microsoft Outlook is shown in this section.
Following are the CRM for Microsoft Outlook implementation tasks specific to Oracle Fusion.
Install Oracle Fusion CRM Applications suite
As a prerequisite setup task, provision the server environment and install the Fusion CRM Applications suite. This task is typically completed by the hosting operations team or customer implementing the Oracle Fusion CRM Applications suite and is the basis for the rest of the setup steps described in this section.
Perform CRM setup tasks for functionality used by CRM for Microsoft Outlook
Because CRM for Microsoft Outlook allows users to access and manage their CRM data in Microsoft Outlook, it is necessary to complete the required setup tasks for the relevant CRM functionality. For example, the following setup tasks must be completed before using CRM for Microsoft Outlook:
Set up reference data, such as: address and phone formats, currencies, geographies, and resources.
Set up CRM functional areas exposed in CRM for Microsoft Outlook, such as: calendar and task management, customer and contact management, lead management, and opportunity and revenue management, including the sales product catalog.
Optionally, CRM for Microsoft Outlook can be configured by completing these Outlook-specific setup tasks:
Configure CRM for Microsoft Outlook client configuration files: Configure only if Outlook client customizations are needed
Configure CRM for Microsoft Outlook client deployment packages: Configure only if Outlook client customizations are needed
Configure CRM for Microsoft Outlook server configuration file: Configure only if Outlook configuration includes references to new services
Other, security-related tasks, performed in Oracle Fusion Authorization Policy Manager (APM), may be necessary depending upon your applications configuration. Perform these tasks after initial setup, as needed. If new job roles are created, you will need to associate these new roles with the predefined data privileges and Outlook configuration packages. If you create custom Outlook deployment packages, there are additional steps required. See the "Related Topics" section at the end of this topic for more information.
Following are the non-Fusion implementation tasks for CRM for Microsoft Outlook.
Verify Microsoft .NET Framework 3.5 SP1 or higher is installed on all computers that run CRM for Microsoft Outlook.
Verify each user has a Microsoft Exchange mail profile configured with Cached Exchange Mode (which supports offline storage in an .OST file format) or has a separate personal folders storage (in .PST file format) to store CRM data.
Deploy the Fusion public certificate into users' Personal and Trusted Root Certificate Authorities directories on users' computers. The certificate is provided by the environment hosting team or the group implementing Fusion CRM. See the related topic, Options for Deploying the Public Certificate: Explained, for steps describing how users can import the certificate themselves or how to automate the process.
Verify that each user can access the CRM for Microsoft Outlook installer from the download page in the Sales application. The download page is accessible from the application preferences menu.
Each user must run the CRM for Microsoft Outlook installer on his/her computer. See the related topic, Deploying and Installing Oracle Fusion CRM for Microsoft Outlook: Explained, for more information.
In Oracle Fusion CRM for Microsoft Outlook, deployment packages contain metadata files that describe the CRM application extensions deployed to users' computers. To provide users access to a new client configuration, you can either create a new deployment package or create a new instance of an existing package, as discussed in the following sections.
When you create a new package, in addition to activating it, you must configure a data security policy that allows users to access the package. This secondary task is done in Oracle Fusion Authorization Policy Manager (APM) and involves the following steps:
In the top left section of the APM
application window, use global search to search for Database Resources
using search criteria equal to Outlook
. This should return the result, Outlook Edition Metadata Package.
Select the Edit button on the Search Results pane to edit the Outlook Edition Metadata Package database resource.
In the Edit Database Resource tab,
select the Condition tab and create a new condition on the database
resource. Specify any unique name/display name, and set the SQL predicate
to package_name = '<name_of_deployment_package>'
(for example, package name = 'NewOutlookPackage'
).
Select the Submit button to commit the change.
Repeat step 2. In the search results pane, select Edit to reopen the Edit Database Resource page to edit the Outlook Edition Metadata Package database resource.
In the Edit Database Resource tab, select the Policy tab, and select the policy that should have access to the new package (for example, ZOE_SALES_MGR_OUTLOOK_DUTY), and then select Edit.
In the lower section of the page, select the Rule tab.
Select the lookup control next to the condition field and select the new condition created in step 3.
Select Submit to commit the changes.
When you use an existing package, you create a new instance of the package with different configuration files. When using this method, you must inactivate the previous instance and activate the new instance. There is no need to configure a data policy when creating a new instance of an existing deployment package.
Before using the Oracle Fusion CRM for Microsoft Outlook application, several setup tasks must be performed. One of these tasks is to deploy the Fusion Public Certificate to each user's machine in order to support secure exchange of data between Outlook and Oracle Fusion CRM during synchronization. The Fusion CRM application public certificate is available from the CRM for Microsoft Outlook preference page in the Oracle Fusion Sales application.
If users have sufficient privileges and knowledge to import the certificate themselves, they need to make sure the certificate is imported to both the Personal and Trusted Root Authority certificate stores. This can be done by following these steps:
In the Windows Start menu select Run, and type mmc to open the Microsoft Machine Console application.
In the console window, select File, then Add/Remove Snap-in.
In the Add/Remove Snap-in window, select Add, and then select the Certificates snap-in. Select the Add button to add it.
Select the option to manage certificates for My user account and select Finish.
Select Close and OK to complete adding the Certificate snap-in.
Expand the Certificates - Current User group to review all the certificate stores.
Expand the Personal store, right-select the Certificates child folder and select All Tasks - Import.
In the next several windows, find the certificate file and complete the import into the Personal certificate store.
Repeat step 7 using the Trusted Root Certification Authorities store, and repeat step 8 to import the certificate file.
Alternatively, to automate the installation of the public certificate into the appropriate certificate stores on the users' computers, deploy the CertMgr.exe program available from Microsoft in the Windows SDK to users' computers, along with the certificate file, and a batch script that implements the following commands:
certmgr.exe -add -c <cert_name> -s root -r localMachine
certmgr.exe -add -c <cert_name> -r CurrentUser -s My
In the script above, the placeholder for the certificate name would be replaced with the name of the certificate file (for example, oracle.cer).
Oracle Fusion CRM for Microsoft Outlook includes a Microsoft Outlook add-in that must be deployed and installed on each user's computer. The installer file is available from the CRM for Microsoft Outlook preference page in the Oracle Fusion Sales application.
Users can complete the installation by running the Oracle Fusion CRM for Microsoft Outlook.msi file on their computers. The Outlook application must be closed during this process. During the install, the user will specify:
The install directory
The Outlook mail profile to use
An alternative to users installing CRM for Microsoft Outlook themselves is for the installer to be deployed to user computers by the administrator using Windows Group policies, Microsoft System Center Configuration Manager (SCCM), or other desktop software deployment mechanisms. In this case, the administrator will access the installer file from the appropriate preference page in the Oracle Fusion Sales application and write a batch script to run the installer with several default parameters, such as the install directory, the mail profile to install to, and all of the elements of the connect string.
The following sample batch script shows how the installer installation can be automated:
msiexec /i "Oracle Fusion CRM for Microsoft Outlook.3.00.50.msi" OL_PROFILE=$DEFAULT FUSION_SERVER_HOST="hostedappserver.com" FUSION_SERVER_PORT="443" FUSION_SERVER_SUFFIX="outlookEditionConnector/OutlookRequestHandlerService" FUSION_SERVER_PROTOCOL="https" /QR
The parameters in the script include the following:
The name and relative path to the installer file. In the example, the script assumes that the .msi file is in the same directory as the batch script.
OL_PROFILE: This is the name of the user's Outlook mail profile. Besides the mail profile name itself, predefined values can be provided (for example, $DEFAULT and $PREFERRED). When using $DEFAULT, the default mail profile will be selected. When using $PREFERRED, the installer will try to use the default profile first, but if it doesn't satisfy the mail profile configuration requirements (if it doesn't use Cached Exchange Mode or use Personal Folders storage) then the installer will try to use another profile.
FUSION_SERVER_HOST: This is the server name or IP address.
FUSION_SERVER_PORT: This is the port that CRM for Microsoft Outlook is configured to use.
FUSION_SERVER_SUFFIX: This is the URL suffix for accessing the CRM for Microsoft Outlook Web services. The one provided in the example above is the default deployment path for the CRM for Microsoft Outlook application, and it will typically be used.
FUSION_SERVER_PROTOCOL: This is either "http" or "https", depending on whether the application is deployed with SSL enabled or not.
Note that the script is using the standard switches provided by the Microsoft Installer executable, msiexec.exe. Documentation of the switches can be reviewed by typing msiexec.exe /?at the command prompt.
Once the installer finishes, the first time the user opens Outlook there will be additional dialogs that prompt the selection of various application options. This process is called the First Run Assistant, and each user will specify:
The Fusion CRM username and password.
The CRM for Microsoft Outlook connect string. Note that if the installation was completed with the various FUSION_SERVER_* variables, the connect string will be pre-filled and the user will not need to specify those details.
Once the user credentials and connect string are provided, the application will connect to Fusion to download and apply the Outlook configuration available to the user. Once the configuration is applied the user is presented with additional First Run Assistant dialogs to complete the personalization process and perform an initial synchronization. In this second phase of the First Run Assistant, the user will specify:
Synchronization settings, including the default synchronization frequency and synchronization filters. The application synchronizes data based on synchronization filters, and will automatically initiate a syncronization on the specified frequency.
Whether to share new Appointments, Contacts, and Tasks in CRM for Microsoft Outlook by default.
Whether to convert his contact list to Fusion contacts.
Once the user completes the First Run Assistant, the application will begin the first synchronization.
Oracle Fusion CRM for Microsoft Outlook is a composite application that allows users to work with Oracle Fusion CRM data inside Microsoft Outlook. The application is deployed to Outlook using the add-in framework and extends the Outlook data model and UI framework in order to store and render CRM data to the user.
Oracle Fusion CRM data is synchronized to users' computers and maintained in native Microsoft Outlook storage. While working in Outlook, users access CRM data that is stored locally, even when connected to the corporate network. The changes made to the CRM data are periodically synchronized with the Oracle Fusion CRM application. There are two options for storing the CRM data:
A Microsoft Outlook mail profile configured to use a Microsoft Exchange service with the Use Cached Exchange Mode enabled to allow data to be stored in an offline storage file (.ost file format)
A Microsoft Outlook mail profile configured to use the Internet E-Mail service with personal folder storage (.pst file format)
Because CRM data is maintained in Outlook storage, it can be displayed and accessed like any other Outlook item. For instance, CRM data types will appear in the folders for the user's mailbox alongside other native Outlook types, and users can select the CRM folder and view the CRM records there as they would work with other Outlook information. Within a given folder, the user can select and open a single record to view the data. In this case, the user will have access to CRM data that appears within an Outlook form or inspector window.
In addition to accessing CRM data in Outlook explorer views and inspector windows where the CRM data is the primary focus, users will also be able to access CRM context when viewing standard Outlook items like appointments, e-mails, and tasks. For these Outlook types, the user will be able to specify the CRM customer, related sales item, contacts, and resources associated with the Outlook item, and will be able navigate to the related CRM item to review additional details.
Data that is stored in either cached Exchange mode in .ost file format, or in personal folders in .pst format, is accessible to the CRM for Microsoft Outlook user while disconnected. The user interacts with the CRM data that is stored locally on his computer and periodically synchronizes data between Outlook and the Fusion CRM server. Synchronization happens when the user is connected to the corporate network and can access the CRM application server. Because the user always works with the local set of CRM data, he will have access to the data from the server immediately following the synchronization process, but doesn't directly access or update the data on the server. Changes are made to the local data set, and then the synchronization process takes care of making changes to the local or server data sets to align the two.
After CRM for Microsoft Outlook is installed, the user must perform an initial synchronization to retrieve his accessible CRM data. Several synchronization settings are configured as part of the First Run Assistant process that influence the initial synchronization. These include the frequency of automatic synchronization, the synchronization filters to use, and which objects are enabled or disabled from synchronization. These settings can be changed by the user after the initial synchronization. Once the user completes the First Run Assistant process, the initial synchronization will begin. The duration of the synchronization process will depend on the number of records that will be synchronized, network bandwidth, load on the server, as well as processing speed and memory available on the user's computer. A rule of thumb is to try to configure synchronization filters so that no more than five to ten thousand records are synchronized.
During the synchronization process, the application performs the following steps:
Connects to the Fusion CRM server CRM for Microsoft Outlook synchronization services using SOAP over HTTP and authenticates the user.
Performs a check to determine the configuration for which the user possesses access. Access to an Outlook configuration is established based on a privilege associated with a user's job role that allows access to an Outlook client deployment package.
If a user has access to a deployment package, it is downloaded, and the configuration is applied to the Outlook mailbox.
The final step is to synchronize data. The records that are retrieved depend on the internal filters configured on the server, data security applied to the objects that are synchronized, and the user filters.
Subsequent synchronization cycles follow a process that includes these steps:
CRM for Microsoft Outlook sends a request to the Fusion CRM server with a list of objects and the current user filters and requests a snapshot of IDs and timestamps for all records that are within the scope of the object list and specified filters.
The server sends a response with the requested information.
CRM for Microsoft Outlook makes a local snapshot of IDs and timestamps and compares that to the server snapshot.
The differences between the local snapshot of IDs and timestamps and the server snapshot result in a few possible actions:
Inserts, updates, or deletes data on the Fusion server based on changes that occurred in CRM for Microsoft Outlook since the prior synchronization.
Inserts, updates, or deletes data in CRM for Microsoft Outlook based on changes that occurred on the Fusion server since the prior synchronization.
In all cases, changes that are made to data locally in the CRM for Microsoft Outlook client are only sent to the Fusion server during the subsequent synchronization session; however, users who want to synchronize a change or set of changes immediately can start the synchronization cycle manually to avoid waiting for the next scheduled synchronization.
The synchronization process on the Fusion server is supported by CRM for Microsoft Outlook accessing Web services. CRM for Microsoft Outlook accesses two Web services directly -- one that provides access to data during synchronization processing, and one that provides access to metadata. The synchronization process is initiated by CRM for Microsoft Outlook within the Outlook application, and the Fusion server accepts synchronization requests, routes them to the appropriate services within the service, and returns the appropriate responses. The work that each part of the synchronization architecture performs is summarized as:
CRM for Microsoft Outlook synchronization engine and connector that are deployed to Microsoft Outlook perform the following:
Initiates a new synchronization request based on a preconfigured automatic synchronization interval or by an ad hoc user request to start a new synchronization cycle.
Uses the stored details about username, password, server connection information, and CRM public security certificate stored on the user's computer to format and send requests to the CRM application server.
Based on the configuration deployed to a user's computer (including object types deployed), fields defined as part of those objects, synchronization filters and the like, the application generates the appropriate SOAP message content and expects the corresponding response when using the HTTP or HTTPS transport to communicate with the CRM applicaiton server.
The Fusion server hosts an application that listens for CRM for Microsoft Outlook synchronization requests, and the synchronization services perform the following:
The OutlookRequestHandlerService Web service processes all incoming requests for data synchronization, and the OutlookMetadataService Web service handles requests to retrieve metadata.
Incoming SOAP messages are routed to the appropriate service. These messages include one or more requests to invoke a method on the target service.
Requests sent to the OutlookRequestHandlerService in particular are routed to other services to perform the action expected from the synchronization process. For instance, a request to get appointment data sent to the OutlookRequestHandlerService will be routed to the appointment Web service that will process the request and return the requested data, and the OutlookRequestHandlerService will send this back to the CRM for Microsoft Outlook client that sent the request.
A synchronization cycle will include requests to get a server snapshot, and can then include many additional requests to query, insert, update, and delete data based on the changes detected when CRM for Microsoft Outlook compares the local and server snapshots.
Each of these requests is processed based on the type of request, and is either managed within the OutlookRequestHandlerService processing directly or is routed to the appropriate target service to be fulfilled.
In addition to standard Outlook data storage mechanisms and the synchronization engine, several extensions to the standard Outlook user interface provide a way to access and manage CRM data inside of Outlook. Examples of extensions to the standard Outlook user interface include custom toolbar buttons, menu items, inspectors that display Fusion CRM data, controls that are embedded on standard Outlook item inspectors, the personalization options dialog box, and so forth. The CRM for Microsoft Outlook client can use these extensions to perform a variety of tasks.
The following are some examples of tasks that the user can perform:
Create, view, and edit CRM data in Outlook.
Mark an Outlook item to be shared with CRM Desktop and associated sales data.
Initiate a standard Outlook action, such as sending an e-mail or scheduling a meeting in the context of a sales item.
The behavior of the extended Outlook user interface is influenced by custom CRM business logic that performs a variety of validations during data entry. The following are some examples of validation that are performed:
Confirm that the data type is valid for a given field.
Make sure fields that are required are populated.
Prevent changes to fields or records that are configured to be read-only.
Validate field values based on comparisons with other fields or static values.
Apply conditional validation so that a field may be required or read-only based on other criteria.
Following are the major physical components that CRM for Microsoft Outlook uses:
CRM Database
This is the database accessed by the CRM application that stores data about customers, contacts, business opportunities, and so on.
CRM Application Server
This is the server that hosts the CRM for Microsoft Outlook application and the related Outlook Web services, and therefore is the main entry point for synchronization requests coming from the CRM for Microsoft Outlook add-in running on users' computers.
Laptop or Desktop
This is the computer where the CRM for Microsoft Outlook add-in is installed, and where users are working with CRM data in Outlook. The Outlook add-in will install binary files that support synchronization of CRM data and integration with Outlook, including support to extend the Outlook data model and user interface, and resource files containing images and strings to initialize the application. The CRM for Microsoft Outlook add-in will connect to the CRM application server and download the appropriate configuration and CRM data for the user which are also stored on this computer.
Corporate Messaging Infrastructure
The corporate messaging infrastructure encompasses all of the server computers and other network topology that support the transmission of e-mail messages, and other personal information management capabilities such as the corporate calendar, contact and task lists.
Following are the CRM for Microsoft Outlook functional components:
CRM Extensions in Outlook
Extensions integrate with Outlook data storage and deliver additional business logic and extensions to the Outlook user interface to allow users to access and modify CRM data. CRM data is viewed with extensions to the Outlook user interface. Changes to CRM data are controlled by business logic and custom controls and then finally stored in Outlook data storage (for example, in a user's mailbox storage file). The user works with a version of the CRM application, as defined in the configuration deployed to the user's computer. Changes to CRM data since the last synchronization cycle are calculated by the synchronization engine during data synchronization with the CRM application server.
Synchronization Engine
The synchronization engine handles requests to initiate a synchronization cycle and is responsible for structuring the requests that are sent to the server. For the initial and incremental synchronization cycles, the synchronization engine manages requests to count records available to the user; sends a request to generate a server snapshot; initiates the process to generate a local snapshot; compares the results; and calculates the necessary requests to be sent to the CRM application server to complete the synchronization of local and server data sets. The synchronization engine works in tandem with the connector to correctly format and transmit messages with the CRM application server.
CRM Connector
This part of the CRM for Microsoft Outlook add-in is responsible for knowing how to connect and communicate with the CRM application server. The connector uses details such as the username, password, connect string, public security certificate, and client metadata to interpret requests from the synchronization engine to correctly format and send requests to the CRM application server. All details of the requests to send to the server are orchestrated by the synchronization engine, but the transmission of the requests and retrieval of the responses is done by the connector. The connector uses the details in the connect string to know where to send requests to the CRM application Web services.
CRM Application Web Service
CRM Web Service provides functionality to handle the user session, and to add, delete, modify, count, and list data objects that are required by the Web service connector.
You can customize the product name displayed by the Oracle Fusion CRM for Microsoft Outlook client, by modifying the package_res.xml client configuration file.
Use an XML editor to open the package_res.xml client configuration file. Create or modify any of the following attributes, as required:
<str key="app_name">CRM for Microsoft Outlook</str>
<str key="pim_name">Outlook</str>
<str key="remote_app_name">Oracle Fusion</str>
For example, in the remote_app_name attribute, change Oracle Fusion to the name of your company.
When a user clicks Send Feedback on the Feedback tab within Oracle Fusion CRM for Microsoft Outlook, a new e-mail message is created, and the e-mail is automatically addressed to the support team. You can customize the support team's e-mail address by modifying the package_res.xml client configuration file.
Use an XML editor to open the package_res.xml client configuration file. In the following code, change email_address to the required e-mail address.
<!-- Feedback page -->
<str key="support_email">email_address</str>
For example:
<str key="support_email">support@your_company.com</str>
You can make Oracle Fusion CRM for Microsoft Outlook fields and forms read-only by modifying the forms.js client configuration file.
Use a JavaScript editor to open the forms.js client configuration file. Find the following code in the configuration file:
// LEAD FORM SCRIPTS //
function lead_form(ctx)
{
The example above shows how to make the Lead field read-only.
To make a field read-only, add the following code below the section of code you have just located:
ctx.form[control_id].enabled = false;
The control_id should be the identifier of the field that you want to make read-only.
To make a form read-only, add the following code below the section of the client configuration file you have just located:
ctx.form.enabled = false;
You can customize the text that appears in the Oracle Fusion CRM for Microsoft Outlook application, by modifying the text strings in the package_res.xml client configuration file.
Use an XML editor to open the package_res.xml client configuration file, and find the text string you want to change. For example, in the following code you want to change the text string "Customer name is required":
<str key="msg_customer_required">Customer name is required.</str>
You change the text string to "Enter a customer name for this organization", and so the code now appears as follows:
<str key="msg_customer_required">Enter a customer name for this organization.</str>
This example demonstrates how to add an Oracle Fusion CRM for Microsoft Outlook button to the Microsoft Outlook 2007 and 2010 Ribbon.
Firstly, you add the button to the Microsoft Outlook Ribbon, by editing either the toolbars_12.xml or the toolbars_14.xml client configuration file. Then you register the button, by editing the application_script.js client configuration file. Lastly, you define what action the button will execute when the button is clicked, by editing the actions.js client configuration file.
<custom_ui for="Microsoft.Outlook.Contact">
...
<tabs>
<tab idMso="TabContact">
<group id="FsnInspector2" label="#toolbar_actions">
<button id="button_id" label="#resource_to_display" size="size" image="resource_for_icon"
getVisible="get_visible" getEnabled="get_enabled" onAction="button_on_action"/>
Substitute the values within the quotation marks with your button information, as follows:
button_id - enter the button's unique ID
resource_to_display - enter the button label
size - enter the button's display size. This can be either small, normal, or large.
resource_for_icon - enter the URL for the button icon
action_manager.add_action("button_id", new actions.some_action, helpers.merge_contexts(toolbar_options, options));
Substitute the following values with your button information:
button_id - enter the ID of the button you want to register
actions.some_action - the action you will define in the actions.js client configuration file
options - options for configuring action control.
The options that you can specify are as follows:
{
"default": <"hidden"> | <"enabled"> | <"disabled"> | <"type_dependent"> | <"type_dependent_disabled">,
"no_selected": <"hidden"> | <"enabled"> | <"disabled"> | <"type_dependent"> | <"type_dependent_disabled">,
"single_selected": <"hidden"> | <"enabled"> | <"disabled"> | <"type_dependent"> | <"type_dependent_disabled">,
"multi_selected": <"hidden"> | <"enabled"> | <"disabled"> | <"type_dependent"> | <"type_dependent_disabled">,
"type_dependence": { <"type_id"> : <"hidden"> | <"enabled"> | <"disabled"> | <"context_dependent_enabled">, ... },
"all_types_state": <"hidden"> | <"enabled"> | <"disabled">
}
The descriptions of these options are as follows:
no_selected - state of the action control when no items are selected
single_selected - state of the action control when a single item is selected
multi_selected - state of the action control when multiple items are selected
type_dependence - state of items by their types (if the state is type_dependent)
all_types_state - state of items by their type, that is not defined in the type_dependence option
The possible states of the options are:
hidden - action control is hidden
enabled - action control is enabled
disabled - action control is disabled
type_dependent - state of the action control depends on the selected item type
type_dependent_disabled - state of the action control depends on the selected item type, but the control state is disabled by default
context_dependent_enabled - state of the action control depends on the context
function some_action(ctx, options) {
this.execute = function (action_ctx) {}
this.is_enabled = function (action_ctx) {}
}
Substitute the following values with your button action information, as follows:
execute - a function that is executed by a button click
is_enabled - a function that returns a boolean value, that determines whether the button is enabled
This example demonstrates how to display a custom Oracle Fusion field in a Oracle Fusion CRM for Microsoft Outlook form. This example specifically shows you how to display the Opportunity Number field on the Opportunity form.
Firstly, you need to make the field Opportunity Number available through the Oracle Fusion API, and then customize CRM desktop to synchronize and display the field.
<Type Key="OptyId" Label="#obj_opportunity"...>
<Field FieldName="OptyNumber" FieldType="xsd:string"></Field>
<type id="opportunity" display_name="#obj_opportunity_plural" folder_type="10">
<field id="OptyNumber">
<reader>
<mapi_user>
<user_field id="fsn Opportunity Number" ol_field_type="1"></user_field>
<convertor>
<string/>
</convertor>
</mapi_user>
</reader>
<writer>
<outlook_user>
<user_field id="fsn Opportunity Number" ol_field_type="1"></user_field>
<convertor>
<string/>
</convertor>
</outlook_user>
</writer>
<str key="lbl_opty_number">Opportunity Number:</str>
<!--end opportunity reason win
los-->
on the Opportunity form.
<!-- opportunity number -->
<cell size="20">
<stack layout="horz" spacing="3">
<cell size="4"/>
<cell size="100">
<stack layout="vert" padding="2">
<cell>
<static id="lbl_opty_number" tab_order="150">
<text>#lbl_opty_number</text>
</static>
</cell>
</stack>
</cell>
<cell>
<edit id="opty_number" tab_order="151">
<field value="string">OptyNumber</field>
</edit>
</cell>
</stack>
</cell>
<!--end opportunity number-->
<!-- opportunity details -->
<cell size="197">
In Oracle Fusion CRM for Microsoft Outlook, a client configuration file describes a part of the application configuration that resides on the user computer, and it extends the desktop application. Client configuration files can either describe a portion of the application logic implemented as Java script, or can be a declarative configuration of items, such as UI components or synchronization mappings implemented as XML. Each configuration file has a particular type. There can be more than one version of any file type at one time as long as the names differ, and only one file of any given type can be included in a deployment package.
In Oracle Fusion CRM for Microsoft Outlook, a client deployment package is a collection of metadata files that describe the CRM application extensions deployed to users' computers. Access to a given deployment package is given to CRM application users through a privilege associated with their job role. When a user connects to the CRM application server to synchronize data from a desktop application like Microsoft Outlook, the application determines if any changes to the package have occurred, and if so, downloads any changes.
In Oracle Fusion CRM for Microsoft Outlook, the client configuration validation file (.xsd) describes the structure of a valid client configuration file (.xml). The application uses the client configuration validation file to check that any client configuration file imported to the server is structured correctly and complies with the requirements of the validation file. The validation process happens automatically during the import of any client configuration file, and helps catch misconfigured files.
The Oracle Fusion CRM for Microsoft Outlook application uses a file to identify and map services and view objects that are used when processing synchronization requests, and to correctly query, insert, update, and delete data on the server. There is only ever one of these files used at a given time, and changes made to it are recognized by the application and loaded immediately.