As we’ve discussed before, most low/no-code orchestrations can be done by citizen developers such as business analysts who have sufficient familiarity with the Orchestrator. However, some projects can initially look simple but turn out to be more complicated. When working with third-party systems outside JDE, you may need custom code to create a workable integration. When the benefit is significant, it’s definitely worth the extra effort. Here’s an example where process automation paid off for a Colorado-based holding company.
The Project Goal: Preventing Bank Fraud with Automated Validation
Account validation is an important step in ensuring that vendors are who they say they are and avoid inadvertently funding fraudulent or even terrorist organizations. To prevent this, our client was vetting individual account data via manual requests. Whenever a vendor's bank account changed, they would send a message to the email address on file with a request for the vendor to fill out a new form for the accounting department.
They wanted a way to make this process much simpler. Fortunately, Wells Fargo provides a streamlined service that can be used to validate any U.S. bank account based on routing and account numbers. Our client wanted to use this service to reduce the amount of time spent on manual validation and ensure nothing slipped through the tracks.
The Problem at Hand: Orchestrator Alone Wouldn’t Work
Bank account information is considered highly sensitive and deserves an extra layer of protection. Many banks require mutual authentication using SSL certificates that provide private keys to decrypt information so it can be read. In the Orchestrator, there was no standard way to communicate with banks using mutual authentication.
The Solution: Custom Code with Groovy and Java Sockets
If you’ve already read our blog post on "How Groovy Script Fills Gaps in the Orchestrator", you know what we tried first. We worked on creating a Groovy script to handle communication with the bank. However, standard HTTP connectors did not work when we were trying to use the Java libraries from Oracle. When Oracle had implemented the version in Orchestrator, they changed several of the methods we needed.
In the end, we had to delve deeper and write custom code from a lower level. We ended up using Java sockets and handling raw data to create the required connections. The Orchestrator and Form Extensions did still play a large role in standardizing the Address Book in JDE as part of the solution.
Here’s a very high-level overview of what we built:
A presentation on the entire solution is uploaded here at Quest.
Lessons We Learned Along the Way
- Orchestrator connections could always be used for SSL (HTTPS)
- Mutual certificates were not supported in standard connections or custom Java/Groovy
- Wells Fargo sandbox can work without mutual certificates
- Test (validation) and Production account validation REQUIRES mutual certificates
- Different Data sets were submitted for Personal vs. Corporate accounts
- Decision Matrix modifications were needed based on data sets
- Mutual Certificates must be manually imported to the AIS server
The Outcome: Major Risk Reduction
This client now has an automated process to validate bank account data prior to making a vendor payment. This automated solution saves time and money by reducing the risk for fraudulent activity. Having this process in place has resulted in measurable process improvements over time.
| First 3-month timeframe | Recent |
|
|
|
|
|
|
|
|
Cutting the percentage of non-validated accounts by more than 50% means the Accounting Department can spend less time tracking down and validating vendor accounts manually. The entire process has end-to-end visibility and there is an audit log as well.
Has Your Orchestrator Integration Project Stalled Out?
Is it something that other people say can’t be done? Do you think it will cost too much? Let our team surprise you with how quick and cost-effective it is to solve your integration problem. Learn about our unique consulting approach here.
