Credit cards are everywhere. Why not use Oracle SOA Suite and create a SOA service that will validate a credit card ?
To implement such a scenario we can use 2 main patterns:
- Create an application that will implement the Luhn algorithm. Expose this application as a web service. Use Oracle SOA Suite and create a composite that will later consume this web service.
- Use an already available web service [aka third party] that validates the credit cards. Use Oracle SOA Suite and create a composite that will use [consume] this third party web service.
Note: This web service is powered by CDYNE Corporation. For more details about CDYNE, please check the "About Us".
We can see all the needed details from the main page LuhnChecker - CheckCC:
both the input type and the output type....or we can just check the LuhnChecker WSDL file.
Disclaimer: Please note this tutorial is for demo only ! No real credit cards will be used. Even the LuhnChecker - CheckCC web service implements the basic Luhn algorithm and nothing more. We will later use different Valid Credit Card Numbers for Testing Purposes!
"Back to the future" SOA service, we will need some specific resources:
- Luhn web service. Based on a specific "CardNumber" string the web service will return a "CardType" string and a "CardValid" boolean output.
- Valid Credit Card Numbers for Testing Purposes.
- cdyne.com SSL certificate.You can download it using the browser or just find it available here: cdynecom.crt.
- KeyStore Explorer tool.
- LuhnChecker_Response.xsd schema.
- LuhnChecker_Input.xsd schema.
Note: Please note that once deployed the composite, you will need to restart the SOA domain.
Now we can open JDeveloper 12c, "File- > New -> Application" and...
Finish.
Since we use a SOAP web service... then it will be "SOAP":
We will place the "SOAP" into the "External References":
Once done, we will go with the below details:
- Name: LuhnChecker_WS
- WSDL URL: https://ws.cdyne.com/creditcardverify/luhnchecker.asmx?WSDL
Once we select the specific "SOAP" operation we will also enable the "copy wsdl" checkbox and "OK":
Use the default and do not select/enable the next checkbox:
All done !
Since for the "US ZIP codes web service with MySQL & GeoNames" we already used a Bpel component ... we will now use the Mediator component.
Till we will implement the Mediator, we need to see how to expose this future composite. How about also as a SOAP web service ?
This approach might raise some question marks since we already have the LuhnChecker web service as SOAP but for demo test we can also learn how to define a service interface manually.
Again the same "SOAP" option - this time however it will be in the "Exposed Services":
We can use the "Client_CheckCC" for the Name and make sure you stop with the Name:
Since this is an internal web service you might ask: what about the "WSDL URL" ? No, there is no such WSDL for now.... So we need to create/define it.
Actually, we do have some default 2 patterns to choose from:
FYI: Looks we will go with option #2: generate WSDL from schemas.
In this scenario, we will generate the new WSDL from schema.... if we already have it. We don't ! We will manually define the input and the output.
Note: Make sure you first select the "Synchronous Interface" and keep all other default options.
Now we can focus on the "Input"; add a new message part, ignore the "Part Name" for now, select the "magnifying glass" URL and then select the top-right icon to import the specific schema that will define this message type: LuhnChecker_Input.xsd schema.
No need to "maintain original directory" and later select the specific element from the new schema & OK:
We can now see the new message part details:
We are done with the INPUT:
We will define now the Output specific details:
No need to "maintain original directory" and later select the specific element from the new schema & OK:
All done, we now have both the Input and the Output defined:
All done. We will define no parameter for the "Fault". Click OK.
Make sure you select the checkbox "copy wsdl". "OK" again.
Now that we have the "service" & "reference" for this composite we now also need the "component" and this will be the Mediator:
Use the "Mediator_LuhnChecker" for the Name and click "OK". Nothing more !
Now we need to link the service with the Mediator component and the reference with the same Mediator component:
Once done, all makes more sense now:
What next ? Of course we need to implement some relevant details on this Mediator side - since for now this is the only part of the composite where we only defined a custom "Name" and nothing more.
Double click on the Mediator .... and no ! The internal Mediator flow looks nothing like Bpel:
Using the Mediator we can implement different tasks/activities but one activity is more special since this activity will be implemented in all Mediators.
It is about the "Transform" activity. This is "a must".
If the Mediator will help us to route the request from the composite client to the external Luhn web service and back then we need to create some transformation rules.
After some seconds you will have a "déjà vu".... like a Bpel "Assign" activity.
First "Transform Using"... Create Mapping and OK.
And again "OK" .
Now we can have that "déjà vu" since we will implement the same idea as within a Bpel "Assign": we link the client input to the Luhn service input:
Click OK. All done here. Save the project and you can close this window.
Back to the Mediator, we will now cover the reply and will follow the same previous scenario:
Here link [drag-and-drop] the below:
- CardType with CreditCard_Brand
- CradValid with Valid_CreditCard
Click OK. All done here. Save the project and you can close this window.
The last window we need to close is the internal Mediator one:
Save all. Close all windows; keep only the composite one:
All done here.
We now need to deploy this composite and use it.
Deployment
---- Deployment finished. ----
Test
Go to EM Console: http://localhost:7601/em/
Use "weblogic" + "welcome1" to Sign In.
For demo credit cards you can use some Valid Credit Card Numbers for Testing Purposes!
Click on the "Test Web Service" ... Get ready to validate some credit cards....
... or just to see an error message....Close enough 😒
Why do we have such issues ?
We can check the error: "Unexpected exception in request response operation "CheckCC" on reference "LuhnChecker_WS". Possible Fix:Check whether the reference service is properly configured and running."
The "LuhnChecker_WS" is pointing to the real Luhn WSDL: https://ws.cdyne.com/creditcardverify/luhnchecker.asmx?WSDL
The "s" from "https" is actually why we are not [yet] able to use this remote web service 😃
Till now we covered no such security details.
Since on the JDeveloper [design time] we had no issues and issues are only in the SOA domain [run time] it looks we need to "do something" in the SOA domain.
Note: Please note you will soon need to restart the SOA domain.
In the below step you will import the cdynecom.crt certificate.
Note: Use the next Alias: *.cdyne.com
You can now restart the server.... but once available back you will have some other new error so we will postpone the restart for now and will go with other more "security" steps.
We will switch from the EM Console to the Admin Console; so open the specific link: http://localhost:7601/console.
Go to servers:
And click on the Admin Server - as the only available server:
Click on the SSL tab and click again on the "Advanced" link:
Here, change the "Hostname Verification" from the default "BEA..." one to "None":
At the end, details will look like below:
You can restart the server... but once available back you will have some other new error so we will postpone the restart and will go with other more "security" steps.
Note: Looks we already did some updates and still have issues so we will stop the server now.
Stop the server !
There is one more test we can do it, the "old fashioned way": we will import the same cdynecom.crt certificate into a key-store manually.
For this we will use the KeyStore Explorer tool. This is a very nice alternative to the command line script.
Go into the BPM binaries location; this is not the DOMAIN HOME ! This is the ORACLE_HOME binaries. In my case is about the "Jdev_BPM_Binaries_Home".
From here we will navigate to the "wlserver\server\lib".
So at the end the location we need is "Jdev_BPM_Binaries_Home\wlserver\server\lib".
Here we have a default key store: DemoTrust.jks.
We will import here this cdynecom.crt certificate.
Using the KeyStore Explorer tool we will open this DemoTrust.jks since the default password is "DemoTrustKeyStorePassPhrase":
We will just drag-and-drop the cdynecom.crt certificate- select the "cdyne" one:
For the Alis use "*.cdyne.com" :
Save and close:
Now start the server back using the custom startWebLogic.cmd.
Go and test again the Luhn composite and you will see that now it works 😉
SoapUI Test
Once more we can go and test this new web service using the SoapUI tool.
Such we can even go with a remote test approach since for now the above EM Console test is still linked with the SOA run-time itself and maybe we want to see how others can use this new service.
Save [copy] your new WSDL location:
And once SoapUI is open go with the "SOAP" test and paste the above link:
