Activate and Run the Recipe

After you've configured the connections and completed the necessary tasks mentioned before, you can activate and run the recipe.

How the Field Service Integration Recipe Works

To understand how the Field Service integration recipe works, review the descriptions in this section.

Note: To confirm that the integration has been activated:

1. In the project workspace, click Activate.
2. In the Activate project panel, with the default project deployment selected, choose an appropriate tracing option, then click Activate.
3. A message confirms that the integration has been activated. Refresh the page to view the updated status of the integration.

Auto Parts Debrief (Integration Name: Oracle Service Logistics OFS Auto Debrief): This integration populates the debrief with parts information if the information is available for the work order. The integration flow between Service Logistics and Field service is as follows:

1. The field service technician starts the debrief process on Oracle Field Service Cloud (OFSC) by clicking the Start button, which starts an activity.
2. This activity raises an event that starts the Oracle Service Logistics OFS Auto Debrief integration.
3. The integration process receives the event details, which includes an activity ID and work order details.
4. The integration process calls an OFSC Rest API to find any parts already added for that debrief task.
5. If there's a part that has already been added, the processing stops.
6. If no part is found for the activity, the integration process calls the CustomerWorkOrders REST API to find the work order that's attached to the activity.
7. The integration process calls another partRequirementLines Rest API for the work order to find the parts already attached to the work order.
8. If there are parts already added with the work order, it tries to add these into the debrief as follows:
   1. Verifies the available parts in the resource inventory by calling the Oracle Field Service REST API (resources/{resourceId}/inventories).
   2. If there's a part, it's added to install inventory by calling the Oracle Field Service REST API (resources/{resourceId}/inventories/{inventoryId}/custom-actions/install)

Custom Rule Processor (Integration Name: Oracle Service Logistics OFS Custom Rule Processor): This is an example of an integration that shows how to use a custom rule for posting charge lines. Processing for this integration is as follows:

1. The integration starts when you post charges, if the Enable Custom Rule Processing when Posting Charges profile is set to Yes.
2. Based on the data, the integration process calls the REST API (debriefs/(debriefHeaderId)) to retrieve the debrief header information.
3. In this example, the customer account information from Step 2 is checked, and only for the specific customer posting the charges. This is done by calling the Auto Process Debrief Charges ESS job and for cases where the charge line is marked as Review.

Note: This is a specific scenario. You can add more complex rules to process based on need.

Debrief Integration (Integration Name: Service Logistics Debrief): Debrief integration between Field Service and Service Logistics happens as follows:

1. When the technician completes the activity in Field Service, an event is raised that triggers this integration.

2. A Field Service REST service (activities/{activityId}/installedInventories) is called to fetch all the labor, parts, and expense debrief lines.

3. A Field Service REST service (activities/{activityId}/deinstalledInventories) is called to fetch all returned parts.

4. A Service Logistics REST service (debriefs/{debriefHeaderId}/child/lines) is called to create the:

   • Debrief transactions

   • Charges

   • Reservations for the parts used (the reservation is released when charges are posted).

5. The Auto Process Debrief Charges job is launched and tries to post the charges automatically, based on a set of rules that you define.

6. The field service administrator must review charges that don't post automatically and post them manually.

7. The debrief information that uploads to Service Logistics includes:

   1. Labor Debrief

      • Service Activity

      • Labor Item

      • Start Time

      • End Time

   2. Material Debrief

      • Service Activity

      • Item Number

      • Quantity

      • Unit of Measure

   3. Expense Debrief

      • Service Activity

      • Expense Item

      • Amount

      • Currency Code

Inventory Balances Download (Integration Name: Service Logistics Inventory): Inventory balances for technician stocking locations are downloaded to Field Service using the following steps:

1. The Oracle Integration flow is a scheduled integration that you can run on demand or on a schedule.

2. A Service Logistics REST Service (stockingLocations REST API) is called to get all technician stocking locations.

3. OFSC Adapter (Resource.Get Resource) is called to check if the stocking location already exists.

4. If the stocking location doesn't exist:

   • OFSC Adapter (Resource.Create Resource) is called to create the stocking location as a truck resource. The truck resource is tied to the parent resource (from profile Default Parent Resource Name).

5. Service Logistics REST Service (trunkStocks ) is called to get inventory balances for the stocking location.

6. OFSC REST Service (resources/custom-actions/bulkUpdateInventories) is called to replace inventory balances in Field Service.

7. The stocking location details that are downloaded to OFSC include:

   • Resource ID (Truck ID)

   • Stocking Location Name (Organization Code + Subinventory Name)

   • Item Number

   • Item Description

   • Item Revision

   • Serial Number

   • On-hand Quantity

   • Primary Unit of Measure

Inventory Balances Incremental Download (Integration Name: Service Logistics Inventory Incremental): Newly updated inventory balances for technician stocking locations are downloaded to Field Service using the following steps:

1. The Oracle Integration flow is a scheduled integration that you should run multiple times a day and every day of the week.

2. A Service Logistics REST Service (stockingLocations REST API) is called to get all technician stocking locations.

3. OFSC Adapter (Resource.Get Resource) is called to check if the stocking location already exists.

4. If the stocking location doesn't exist:

   • OFSC Adapter (Resource.Create Resource) is called to create the stocking location as a truck resource. The truck resource is tied to the parent resource (from profile Default Parent Resource Name).

5. The Inventory REST Service (inventoryCompletedTransactions) is called to find all items that have been transacted on the current day.

6. The Service Logistics REST Service (trunkStocks) is called to get inventory balances for the item.

7. The OFSC REST Service (resources/custom-actions/bulkUpdateInventories) is called to create or update inventory balances in Field Service.

8. The stocking location details that are downloaded to OFSC include:

   • Resource ID (Truck ID)

   • Stocking Location Name (Organization Code + Subinventory Name)

   • Item Number

   • Item Description

   • Item Revision

   • Serial Number

   • On-hand Quantity

   • Primary Unit of Measure

Order Parts for an Activity (Integration Name: Service Logistics Order Parts): Parts orders integration between Service Logistics and Field Service occurs as follows:

1. Field service technicians click the Order button to order parts from OFSC using Service Logistics.

2. This creates an order activity in OFSC.

3. Step 1 raises an event that triggers the integration.

4. An OFSC Adapter (Activity Inventory) is called to get all the parts ordered by the technician.

5. The data elements passed from OFSC to Service Logistics are:

   • Item Number

   • Quantity

   • Unit of Measure

   • Ship To Address Type (Technician or Customer)

   • Work Order ID (Fusion Service Work Order ID)

6. A Service Logistics REST service (partRequirementLines) is called to create part requirements and find a supply source (partRequirementLines/{partsReqLineId}/action/getPreferredSource).

7. The supply orchestration REST service (supplyRequests) is used to create the transfer order to ship the parts to the technician or to the customer site.

8. The parts ordered by the field service technician for the work order appear in the Oracle Field Service work order, along with other parts that ordered by the agent using the Fusion Service pages.

9. If the part isn't found, a backorder is created for the replenishment source.

10. The following is downloaded to OFSC:

    • Transfer order number

    • Order activity status

    • Transfer order header ID

Note: Field service technicians can order more than one part number and more than one quantity of the part.

Receive Parts (Integration Name: Service Logistics Receive Parts): This integration completes the receiving parts process by a field service technician. The integration between Service Logistics and Field Service occurs as follows:

1. The field service technician provides the received item quantity and clicks the Receive button, which starts the receiving process.

   The application:

   • Creates an activity in Oracle Field Service.
   • Raises an event that triggers the Service Logistics Receive Parts integration.

2. The integration process retrieves the activity details from Oracle Field Service Cloud using the Oracle Field Service Adapter (Activity).

3. The application calls an Inventory Management REST service (linesToReceive) to retrieve the expected shipment lines that can be received using the activity detail information (part item number and transfer order header ID).

4. If the application finds a valid shipment line, it calls another Inventory Management REST service (receivingTransaction) to create a receive transfer order. The application passes the following parameters while creating this transfer order transaction:

   • Quantity and UOM Code from Oracle Field Service Activity details.
   • Item number, Shipment Header Id, Shipment Line Id.
   • Destination Type code defaults to INVENTORY, Source Document Code to TRANSFER ORDER, and Transaction Type to RECEIPT.

Order Parts to Replenish Trunk Stock (Integration Name: Service Logistics Replenish Parts): Parts orders integration between Service Logistics and Field Service occurs as follows:

1. Field service technicians click the Order button to order parts from OFSC to replenish their trunk stock.

2. This creates an order activity in OFSC.

3. Step 1 raises an event that triggers the integration.

4. An OFSC Adapter (Activity Inventory) is called to get all the parts ordered by the technician.

5. The data elements passed from OFSC to Service Logistics are:

   • Item Number

   • Quantity

   • Unit of Measure

   • Ship To Address Type (Technician or Customer)

   • Work Order ID (Fusion Service Work Order ID)

6. A Service Logistics REST service (partRequirementLines) is called to create part requirements and find a supply source (partRequirementLines/{partsReqLineId}/action/getPreferredSource).

7. The supply orchestration REST service (supplyRequests) is used to create the transfer order to ship the parts to the technician or to the customer site.

8. If the part isn't found, a backorder is created for the replenishment source.

9. The following is downloaded to OFSC:

   • Transfer order number

   • Order activity status

   • Transfer order header ID

Note: Field service technicians can order more than one part number and more than one quantity of the part.

Part Item Number Download (Integration Name: Service Logistics Parts Catalog): Field Service Technicians need part item numbers to order replacement parts. Part item numbers are downloaded using the following process:

1. A batch program loads items from the Oracle Product Information Cloud to Field Service using Oracle Integration. The batch program is an OIC integration program that can be run on demand or scheduled to run from OIC.

2. This integration downloads all items for the inventory organization defined in profile Default Inventory Organization. Only items with Service Logistics Billing Type tied to Billing Category = Material are included. The item details downloaded include:

   • Item Number

   • Item Description

   • Item Revision

   • Primary Unit of Measure

   Note: You must set up the labor and expense items in OFSC to match the labor and expense items in the item master in Product Information Management. See Chapter 4 for details.

Preventive Maintenance (Integration Name: Service Logistics Preventive Maintenance): This is a scheduled integration for generating preventive maintenance work orders.

1. Schedule Oracle Integration Service Logistics Preventive Maintenance to run on a daily or weekly basis.

2. This integration accepts the following five parameters:

   • MaintenanceOrganizationCode: Short name of the maintenance organization that runs the preventive work.

   • Category: Category for the service request.

   • WorkOrderIntegrationCd: Use ORA_WO_INT_OFSC for Oracle Field Service Cloud (OFSC) work order creation or ORA_WO_INT_SVC for generic work order creation.

   • WorkOrderStatusCode: Initial status code used for creating the work order.

   • WorkOrderTypeCd: Work order type code used for creating the work order.

3. This integration starts with setting a default time zone, which you can change based on the customer's time zone.

4. Based on the organization code and work order type code passed as input, the application retrieves the corresponding identifier to pass for the process.

5. The application calls Maintenance REST service (MaintenanceWorkOrders) to retrieve all released customer assets-based work orders with future planned start dates.

6. For each maintenance work order returned by the previous process, the application does the following:

   • Calls the Maintenance REST service (DocumentReference) to check for document reference of type ORA_SERVICE_REQUEST against the current maintenance work order. If there's reference data, then it skips processing.

   • If there's no reference data, the application retrieves current asset details information by calling an SCM REST service (installBaseAssets).

   • If the asset detail is missing the asset location, then it skips the processing. Otherwise, it calls the HCM SOAP API (LocationService) for the asset’s current location ID to retrieve location details.

   • The application calls the SCM REST service (WorkDefinition) to retrieve work definition details based on the maintenance work order work definition ID. The application then calls CRM REST service (Contact) for the asset’s contact details.

   • For an OFSC work order creation (based on the parameter that you set up before), the application retrieves the work area by calling the CRM REST service (svcWOAreas). By default, the country and postal code are passed to this rest service, but you can provide more parameters based on your setup.

   • For an OFSC work order creation: If there's an error during the work area retrieval processing, then the processing stops for the current maintenance work order.

   • Based on the service request category, the application calls the CRM REST service (Categories) to retrieve the category ID and then calls another CRM REST service using the customer number and customer site number for the asset to retrieve the asset address.

   • Create a service request by calling the CRM REST service (ServiceRequests) with the following parameters:

     • Title: Work definition name.

     • Problem Description: Work definition name description.

     • Account Party Id: Asset customer ID.

     • Primary Contact Party Id: Party ID from the contact details based on the asset contact.

     • Inventory Item Id: Asset item.

     • IB Asset Id: Asset ID.

     • Category Id: ID retrieved based on the service category name passed as the schedule parameter.

   • Create a work order by calling the CRM REST service (CustomerWorkOrders) with following parameters:

     • Title: Work definition name.

     • SId: Service request ID.

     • Account Party Id: Asset customer ID.

     • Contact Party Id: Party ID from contact details based on the asset contact.

     • IB Asset Id: Asset ID.

     • Wo Integration Cd, Work Order Status Code: From the corresponding input parameter.

     • Wo Type Id: Retrieved at the beginning of the processing based on the input provided as work order typeCd.

     • Wo Area: For OFSC work order, it's retrieved as mentioned.

     • Resolution Due Date: Planned completion date from maintenance work order.

     • Contact Name, Contact Email, Contact Phone: Contact details retrieved based on the asset’s contact id as mentioned.

     • Address Component: Address details retrieved by calling SOAP API as mentioned.

     • Time Zone Code: Value of the default time zone as set in the integration.

   • For the current maintenance work order the application calls another SCM REST service (maintenanceWorkOrder) to find the maintenance operations that the work order requires. For each of these operations do the following:

     • For the current maintenance work order call the SCM REST service (maintenanceWorkOrders/{WorkOrderId}/child/WorkOrderOperation/{WoOperationId}/child/WorkOrderOperationMaterial) to find materials that the work order requires to perform a maintenance operation.

   • For each material create a part requirement line based on the following attribute mapping:

     • Destination Organization Id: Organization ID of the operation.

     • Need-by Date: Planned start date of operation.

     • Parent Entity Id: Work Order ID created during this integration processing.

     • Inventory Item Id, Quantity, UOM Code: As defined in operation materials.

     • Ship-to Address Type: Defaults as CUSTOMER.

     • Ship-to Party Id: Service request account party ID.

   • The application calls the Maintenance REST service (maintenanceWorkOrders/{WorkOrderId}/child/documentReference) to record the reference data based on the following parameters:

     • Source System Type Code: Defaults to ORA_INTERNAL.

     • Work Order Id: Maintenance work order ID that the integration is currently processing.

     • Document Type: Defaults to ORA_SERVICE_REQUEST.

     • Document Header Id: Service request ID that's created during processing.

7. Error Handling: This scheduled integration creates service requests, work orders, and part requirement lines. It also validates various attributes. If there's a failure during processing, then the application:

   • Stops the processing for that maintenance work order.

   • Logs the message.

   • Deletes any data that it created during the processing, such as service requests, work orders, or part requirement lines.

Technician Download (Integration Name: Service Logistics Technician): Service Logistics field service technicians are downloaded to Field Service according to the following steps:

1. The Oracle Integration flow is a scheduled integration that you can run on demand or on a schedule.

2. A SOAP Service (PersonService.findPerson) is called to get a list of all field service technicians.

3. An OFSC Adapter (resources.Update Resource) is called to update the technician resource if it already exists.

4. If resource doesn't exist:

   • A common REST Service (profileValues) is called to get the parent node for the resource from profile Default Parent Resource Name.

   • OFSC Adapter (Resource.Create Resource) is called to create the resource. The field service technician resource being created will be assigned a parent resource as defined in the profile.

5. The technician details that are downloaded to OFSC include:

   • Parent Resource

   • Person Party ID

   • Full Name

   • Email

   • Mobile Phone Number

   • Status(active/inactive)

Note: You can run:

• Inventory balances integrations to store inventory on a truck resource.

• Technician inventory balances integrations to store inventory on a technician resource directly.

Technician Inventory Balances Download (Integration Name: Service Logistics Technician Inventory): Inventory balances for technician's default usable subinventory are downloaded to Field Service using the following steps:

1. The Oracle Integration is a scheduled integration that you can run on demand or on a schedule.

2. The Service Logistics REST Service (stockingLocations REST API) is called to get all the technician default usable stocking locations.

3. The Service Logistics REST Service (trunkStocks) is called to get inventory balances for the stocking location.

4. The OFSC REST Service (resources/custom-actions/bulkUpdateInventories) is called to replace inventory balances in Field Service.

5. The stocking location details that are downloaded to OFSC include:

   • Resource ID (Technician Party ID)

   • Stocking Location Name (Organization Code + Subinventory Name)

   • Item Number

   • Item Description

   • Item Revision

   • Serial Number

   • On-hand Quantity

   • Primary Unit of Measure

Technician Inventory Balances Incremental Download (Integration Name: Service Logistics Technician Inventory Incremental): Newly updated inventory balances for technician's default usable stocking locations are downloaded to Field Service using the following steps:

1. The Oracle Integration is a scheduled integration that you should run multiple times in a day and every day of the week.

2. The Service Logistics REST Service (stockingLocations REST API) is called to get all the technician default usable stocking locations.

3. The Inventory REST Service (inventoryCompletedTransactions) is called to find all items that have been transacted on the current day.

4. The Service Logistics REST Service (trunkStocks) is called to get inventory balances for the item.

5. The OFSC REST Service (resources/custom-actions/bulkUpdateInventories) is called to update inventory balances in Field Service.

6. The stocking location details that are downloaded to OFSC include:

   • Resource ID (Technician Party ID)

   • Stocking Location Name (Organization Code + Subinventory Name)

   • Item Number

   • Item Description

   • Item Revision

   • Serial Number

   • On-hand Quantity

   • Primary Unit of Measure