Nowadays the cloud solutions are covering everywhere in daily lives by thousands of providers - daily expenses, property management, online stores, project management, customer relationship management, or even smart house technologies.
The advantages of using cloud solutions are so obvious - cost efficiency, (almost) unlimited storage, easy accessibility, instant deployment, etc.. It becomes a phenomenon despite of some disadvantages such as data management delegation to third party, security (mobile phone), and some confusions (cloud services are usually mutually independent between providers).
From the other side of the door there are so many topics quarrelling between the cloud solutions and existing ERP systems and that's it. However I do remember a coffee talk with a client around how inconvenient it is to submit business travel expense reports, and Friday afternoon timesheets - set a reminder somewhere, every time, go to the office, logon to the system on intranet, and submit data before manager or accounting team calls up.
It would be a bit fancier to use iPhone/Android apps on bus or train to submit these kinds of raw data if there are not that critical as the processed data (Payroll, General Ledger, you name it) - please correct my opinion if I'm wrong.
Our ERP systems are usually powerful enough to provide such mobile solutions however probably it won't be very easy to be approved by in-house security managers. Leave the port open to external world will be a HUGE risk because the critical data are usually hosted by the same database. The idea came to my mind is, probably, to segregate these types of pre-processing data transactions from ERP mainframe, to the easy fancy cloud services (which usually have their own mobile apps delivered).
So, with the idea in my mind, recently I tried a free-to-use cloud service and probably (just because it's free) I can use it to present my idea in this post. It does have mobile apps but I just used its web page version for taking screen shots easily.
Below is the screen shot of one example Expense record. Nothing shining too much.
On the market cloud services are providing their own API. They do have different levels of security settings. Since I'm using the FREE version, probably the AUTHTOKEN method is the only thing I can get.
This API is based on RESTful web service, which is extremely popular these days but just NOT too well supported by PeopleSoft before. BTW the recent PeopleTools versions (especially PT8.54) are covering RESTful though.
Below is a response message (in JSON format, typically) from the cloud service provider (SoapUI is a good friend). The right panel shows the data brought back by the JSON message.
The cloud service is open to the whole world. Everyone with the provided security policy will have the access to the data directly and easily, as well as our ERP system (and other hackers too). It won't be a good idea to have any core system exposed to the external, so there should be an agent who can do the job for the core system.
To bridge our ERP system to external cloud service, the agent should 1) hide our core system from external risks; 2) transfer the message between cloud services and our core; 3) transform the message if required; 4) trigger some workflow if required, etc. Here I'll leave the security topic to security experts and continue this demo.
There are many other competitive integration tools such as TIBCO, MuleSoft on the market. I used Oracle's SOA Suite to be this agent, just because it is easy for me to download, install and use.
Below is the screenshot of one SOA application built by JDeveloper 12c, which (finally) has the REST adapter packaged. Very quickly I made a BPEL process which provides 2 ports, one for our ERP system (in this example, PeopleSoft), and another one is to call the cloud service out there. In this design the process has only ONE direction that only our SOA can call the cloud service but not the other way around. The SOAPService is based on WSDL, which has been well used by PeopleSoft since ages ago.
Because the cloud service is based on HTTPS, I need to make a CA cert for SOA Suite's web server (JDeveloper 12c's integrated weblogic, in my case).
Now the communication channel between SOA Suite and external cloud service has been built successfully. Tested the Web Service and got the good response message (200 OK).
My very expensive Host machine "Tarzan" is assigned with IP address 192.168.56.1. The JDeveloper 12c integrated Weblogic is running with port 7102 listening to HTTPS and 7101 to HTTP.
In real life we will consider to follow the security standards - such as using HTTPS to build up the communication between PeopleSoft and SOA Suite webservice (the "SOAPService" mentioned above). To simplify this demonstration, I just used HTTP protocol - port 7101.
So instead of using the original URL "https://Tarzan:7102/soa-infra/services/default/RestfulWS/SOAPService?WSDL", now I'm using "http://192.168.56.1:7101/soa-infra/services/default/RestfulWS/SOAPService?wsdl" to complete my PeopleSoft side demonstration.
Yes, it's Integration Broker here.
By now a PeopleSoft service SOAPSERVICE has been successfully built.
The following work will be on PeopleSoft side - digest the WSDL message with PeopleCode, call Component Interface to save the data (to Time&Labor TRC or Travel&Expenses entry or Payroll Earning/Deduction or Absences or Journal Entry or ...), process the data and then keep the BAU running.
And this is just a not-certified idea to have cloud services work with existing ERP system.
Done.
No comments:
Post a Comment