INT CM01 Oracle External Cash

Import Integration approaches

Integration Design Document

v1.0 – 11/16/2018

2018 UCLA Business Transformation Office

CM – Cash External Import – Integration Design Document

Document Tracking

Document Location
Revision History

Revision Date Author Summary of Changes

Reviewers

Name Role Organization Review Date

Approvals

Name Role Organization Review Date

2
CM – Cash External Import – Integration Design Document

Contents

I. Purpose......................................................................................................................................... 4
II. Interaction Specifications .......................................................................................................... 4
1. Introduction ...................................................................................................................................................... 4
2. System Analysis and Flow ............................................................................................................................ 4
2.1. Functional Requirements .............................................................................................................................. 5
2.2. Assumptions .................................................................................................................................................... 5
2.3. Interface Specifications ................................................................................................................................. 6
2.4. Integration approach – FBDI automation .................................................................................................. 7
2.4.1. FBDI Integration process flow ...................................................................................................................................................7
2.4.2. Interface Mapping ........................................................................................................................................................................8
2.4.3. Sample payload ............................................................................................................................................................................8

2.5. Integration approach – REST webservice ................................................................................................ 9

2.5.1. REST Integration Processflow ..................................................................................................................................................9
2.5.2. Prerequisites and Dependencies ...........................................................................................................................................10
2.5.3. Interface mapping ......................................................................................................................................................................10
2.5.4. Sample payload ..........................................................................................................................................................................10
2.5.5. Error handling ............................................................................................................................................................................. 11

2.6. Integration approach – SOAP webservice .............................................................................................. 11

2.6.1. SOAP Integration Processflow ................................................................................................................................................12
2.6.2. Prerequisites and Dependencies ...........................................................................................................................................12
2.6.3. Interface mapping ......................................................................................................................................................................13
2.6.4. Sample Payload .........................................................................................................................................................................13
2.6.5. Error handling .............................................................................................................................................................................13

4.1. Integration Test Plan .................................................................................................................................... 14

4.2. Logging ........................................................................................................................................................... 14
5. Appendix..................................................................................................................................... 14
5.1. Appendix A: Design Decisions .................................................................................................................. 14
5.2. Appendix B: Non-Functional Scope ......................................................................................................... 14
5.3. Appendix B: Follow-Ups Required ........................................................................................................... 14
5.4. References ..................................................................................................................................................... 15

3
CM – Cash External Import – Integration Design Document

I. Purpose
This document attempts to explain the different design approaches one can take up while integrating
external cash transactions to Fusion Financial system part of Cash Management cycle. There are various
factors viz. boundary system capability, volume of transaction, business flow etc., which will pave out the
desired integration technique from the available options illustrated in this document.

II. Interaction Specifications

1. Introduction
Oracle considers External cash transactions as transactions related to cash activity that has not been
recorded within the fusion applications in any of the subledger modules. There could be various ways
Oracle can accept these transactions, viz.

- Manual Entry in Cash Management

- Import: feed through FBDI/ Webservices)
- Balancing Transactions: Transactions created during reconciliation program run to record amount
differences between the statement line and system transaction
- Bank Statement: bank statement transaction creation program allows you to configure rules to
create transactions from unreconciled statement lines to record items such as bank charges, interest,
or other miscellaneous items

The import process is being considered here for automation of External Cash Import process flow.

2. System Analysis and Flow

The inbound integration process would involve boundary system as the source system sending
external cash transaction information to the target system (Oracle Fusion ERP).

If there’s a volume load coming in, existing MFT infrastructure can be repurposed in the integration
landscape. Middleware will transform the data received from MFT in the desired Oracle format, and
will do necessary orchestration before invoking out of box batch load webservices to upload them
into Fusion ERP system.

There are separate SOAP/ REST APIs being provided by Oracle for synchronous and on the fly
External Cash Import transactions. If need be so, Source systems can directly invoke these
webservices and send the data into Oracle Cash Management. This would be a more light weight
process and would bypass all the heavylifting done by MFT and middleware at the target end.

4
CM – Cash External Import – Integration Design Document

In a generic term, volume data is recommended to be imported through FBDI automation technique,
and low volume data can be imported using web services in synchronous fashion. However, there
could be other factors such as boundary system capability and other integration preferences that can
guide the integration approach eventually.

Figure 1: Interaction Context Diagram

2.1. Functional Requirements

UCLA has multiple systems that they maintain for a variety of business activities each of which
generates financial transactions on a daily basis.

For instance, the CASHNet system receives deposits from multiple sources which are either
unidentified or not related to Receivables transactions. The various sources for these deposits are
eMarket Sites (Student & Non-Student), Departments, Deposit Returns (ACH & Electronic), Foreign
Currency Payments via Western Union, General Deposits on behalf of Departments etc.

In addition, there are payments that are processed through CASHNet which are considered as
Negative External Transactions.

Sources like CASHNet (and other sources as disclosed by UCLA during functional requirement
gathering process) and their different receipts/ payments need to be finalized in order to understand
the overall integration need involving boundary systems, volume etc. for Oracle External Cash
Transactions.

User Story # Scenario

2.2. Assumptions
The following are the assumptions for External Cash Transaction:

5
CM – Cash External Import – Integration Design Document

a) Current scope of the document is : FSRI BTO

2.3. Interface Specifications

Integration External Cash Transaction

Exception All the error codes and error descriptons can be sent as per source system requirements
processing
Triggers Source data file (Batch processing)/ User input (real time)

Co-Existence
Consideration
Source-Target Type Transport Data Format Syn/Async Complexity

FileTransfer Delimited,
Source - MFT SFTP preferably FBDI Async Low
csv format
FileTransfer Queue/ Delimited,
MFT - OIC Webservice/ preferably FBDI Async Low
SFTP csv format
WebService SOAP XML/
OIC - Oracle SOAP/ REST Sync Complex
REST JSON
OIC – MFT FileTransfer Error files in CSV
SFTP Async Complex
(optional) format

6
CM – Cash External Import – Integration Design Document

2.4. Integration approach – FBDI automation

This section illustrates the automation technique that can be followed for batch import of Cash
transaction data from a source leveraging Oracle FBDI principle.

2.4.1. FBDI Integration process flow

In this section, we describe the solution approach to build orchestrated process with OIC for receiving
External Cash Transaction data from source system and upload them to Oracle Fusion ERP.

Figure 2: Logical Interaction Context Diagram

Below are the steps involved in the overall solution approach.

1. Source systems send the files either in FBDI layout format or source native format. These files
are received in MFT.

a. If files are received in FBDI format, integration middleware platform (OIC) reads them and
compresses with base64 encoding.
b. if files are received in NON-FBDI format, integration middleware platform (OIC) picks them up
and does a target FBDI transformation first, before compressing the data with base64
encoding.
The file reading can be done through MFT configuration as a queue OR with webservices OR it
can be an SFTP read.

2. Orchestrated flow in OIC pushes the file content to Oracle UCM using Oracle out of box
webService ERPIntegrationService, and triggers the ESS process in Oracle fusion which loads
Cash Transactions into CE_EXTERNAL_TRANSACTIONS table.

3. Once the import is complete, OIC integration flow receives call back notification from Oracle
Cloud with status of ESS jobs.

4. OIC integration intereprets the call back SOAP XML, prepares the Error message in case ESS
job completes in Error or Warning, and sends a notification back to users with ESS Job details
that faltered.

7
CM – Cash External Import – Integration Design Document

5. Archive the source file in appropriate directory based on the outcome of the integration, for audit
trail.

6. User can login to the system on receiving error notification and use the Correct Import Errors
Spreadsheet to make corrections and reprocess.

7. Optionally OIC can trigger a custom BI Report to gather the error information and put that in a
storage/ MFT as file and send a link in notification.

2.4.2. Prerequisites and Dependencies

# Dependency Reason
1. Legal Entity, GL Cash
Account, Bank, Bank
branch and bank account
information needs to be
setup in Fusion ERP.
2 A generic Integration user
needs to be setup in
Fusion ERP

2.4.3. Interface Mapping

FBDIDataMapping.xls
x

2.4.4. Sample payload

UCMLoad.xml SubmitEss.xml GetESSJobStatus.xml

2.4.5. Error handling

The error handling and troubleshooting section describes the details of exception handling requirements
for External Cash Import Interface
# Error Scenario Expected Results
1 User is not available in Authentication will fail and user will be redirected to error page.
Oracle Cloud
2 Oracle Cloud throws error message is received from the application via webservice
exception/error while response. Based on error message, correction needs to be done

8
CM – Cash External Import – Integration Design Document

creating external import before reprocessing.

with SOAP Call. There
could be various invalid
scenarios like invalid
Bank Account/ Legal
entity/ Business Unit, GL
CCID, Date format etc.

All the error messages per transaction can be sent over to applications maintaining audit trail, and in
parallel to users in email.

2.5. Integration approach – REST webservice

This section illustrates the integration technique that can be followed for real time import of External Cash
transaction data from a source leveraging Oracle out of box REST API.

Request
Response

Target system (Oracle ERP)

Optional OIC orchestration
Source system(s)

OIC
Data Transform
file Read

MFT
Error Invoke Request
ErrorLog Webservice Response
file

Figure 3: REST Integration Diagram

2.5.1. REST Integration Processflow

Below are the steps involved in the overall solution approach for External Cash Import process. These
steps can be carried out by the source independently OR the target system.

9
CM – Cash External Import – Integration Design Document

1. Invoke the Oracle out of box REST API for Extrenal Cash Import as documented at
https://docs.oracle.com/en/cloud/saas/financials/18c/farfa/api-external-cash-transactions.html

2. For a successful transaction on Oracle end, status code 201 is returned. The application response
message would contain the source payload as bounce back alongwith certain key values like
Transaction ID, auto generated External Transaction ID, last Update Date and login info etc. A
custom success message can be returned to the invoker system as needed alongwith the keys for
audit trail.

3. On Error, a different status other than 201 is returned. Data correction will be needed as per the
returned error message in order to reprocess the transaction from source.

4. Depending on the integration platform (at source), error messages can further be customized and
orchestrated for notification and audit trail purpose. If integration is performed at the target end, OIC
can generate custom error message and send the same to users as notification.

2.5.2. Prerequisites and Dependencies

# Dependency Reason
1. Legal Entity, GL Cash
Account, Bank, Bank
branch and bank account
information needs to be
setup in Fusion ERP.
2 A generic Integration user
needs to be setup in
Fusion ERP

2.5.3. Interface mapping

RESTAPIDataMappin
g.xlsx

2.5.4. Sample payload

10
CM – Cash External Import – Integration Design Document

2.5.5. Error handling

The error handling and troubleshooting section describes the details of exception handling requirements
for External Cash Import Interface
# Error Scenario Expected Results
1 User is not available in Authentication will fail and user will be redirected to error page.
Oracle Cloud
2 Oracle Cloud throws error message is received from the application via webservice
exception/error while response. Based on error message, correction needs to be done
creating external import before reprocessing.
with SOAP Call. There
could be various invalid
scenarios like invalid
Bank Account/ Legal
entity/ Business Unit, GL
CCID, Date format etc.

All the error messages per transaction can be sent over to applications maintaining audit trail, and in
parallel to users in email.

2.6. Integration approach – SOAP webservice

This section illustrates the integration technique that can be followed for real time import of External Cash
transaction data from a source leveraging Oracle out of box SOAP API.

11
CM – Cash External Import – Integration Design Document

Request
Response

Target system (Oracle ERP)

Optional OIC orchestration
Source system(s)

OIC
Data Transform
file Read

MFT
Error Invoke Request
ErrorLog Webservice Response
file

Figure 4: SOAP integration Diagram

2.6.1. SOAP Integration Processflow

Below are the steps involved in the overall solution approach for External Cash Import process. These
steps can be carried out by the source independently OR the target system.

1. Invoke the Oracle out of box SOAP API for Extrenal Cash Import with webservice URL as
<POD>/fscmService/ExternalTransactionServiceService?WSDL

2. For a successful transaction on Oracle end, a success message is received. A custom success
message can be returned to the invoker system as needed alongwith the key values for audit trail.

3. On Error, a different status other than Success is returned. Data correction will be needed as per the
returned error message in order to reprocess the transaction from source.

4. Depending on the integration platform (at source), error messages can further be customized and
orchestrated for notification and audit trail purpose. If integration is performed at the target end, OIC
can generate custom error message and send the same to users as notification.

2.6.2. Prerequisites and Dependencies

12
CM – Cash External Import – Integration Design Document

# Dependency Reason
1. Legal Entity, GL Cash
Account, Bank, Bank
branch and bank account
information needs to be
setup in Fusion ERP.
2 A generic Integration user
needs to be setup in
Fusion ERP

2.6.3. Interface mapping

SOAPAPIDataMappin
g.xlsx

2.6.4. Sample Payload

CMExternalCashTran
saction-soapui-project.xml

2.6.5. Error handling

The error handling and troubleshooting section describes the details of exception handling requirements
for External Cash Import Interface
# Error Scenario Expected Results
1 User is not available in Authentication will fail and user will be redirected to error page.
Oracle Cloud
2 Oracle Cloud throws error message is received from the application via webservice
exception/error while response. Based on error message, correction needs to be done
creating external import before reprocessing.
with SOAP Call. There
could be various invalid
scenarios like invalid
Bank Account/ Legal
entity/ Business Unit, GL
CCID, Date format etc.

All the error messages per transaction can be sent over to applications maintaining
audit trail, and in parallel to users in email.

13
CM – Cash External Import – Integration Design Document

3. Integration Test Plan

This section describes the details of testing scenarios and test cases for each components and business
functionalities of the External Cash Import. Manual test strategies will be used to test the functionalities.
ID Test Scenario Expected Results GUnit / Self-
Manual Contained/
Repeatable




4. Logging
1. All Errors will be logged in an application log file with appropriate error details.
2. The structure of each log entry will be as follows:

log.error(“${OIC_Flow_Id}-${Process_Name} – ${ErrorDescription}”) // exceptions, include stack-

trace, error code and description

5. Appendix

5.1. Appendix A: Design Decisions

None

5.2. Appendix B: Non-Functional Scope

Interaction
NFR # Brief Description
Scenario

Security :  Authorization: None

SourceSystem   Authentication : SSO
External Cash Oracle Cloud
Management Performance Not Applicable
Availability
Projected Volumes Not Applicable
Time-out 30 seconds

5.3. Appendix B: Follow-Ups Required

None

14
CM – Cash External Import – Integration Design Document

5.4. References
Following are a list of reference documentations which provides further details on the architecture,
requirements, design approaches, etc. those used in Import Journal Integration Design Document.

 Functional Configuration Documentation

 Any Architecture Document

15