My client is using functionality from 3rd party oracle ADF applications manually. That functionality is calculation of insurance price for various types of vehicles. They enter data in forms and print a report. They have 4 different 3rd party systems and after submission in all 4 systems they are comparing reports and search for best insurance deals. It's slow and these reports are all different and hard to compare.
My task is propose a way how can we make one application for data input and reports and what that 3rd parties must do on their end. That application would communicate insurance data with theese 3rd party application, and get prices and other data. They are using Oracle ADF application, and I am not sure what is the most efficient way to do that communication ? Are the Web Services way to go ? Or there is some other way to do that ?
If the functionality is coded in PLSQL, then you can call PLSQL directly from the ADF BC layer (EO).
Or, yes, you can expose the functionality as a WS and consume this from the ADF BC layer either wrapped in a POJO or as a data control in its own right, exposed on a JSF page.
Related
My question is regarding the clean architecture. I am quite new to .NET Core, and my assignment is to integrate a third-party API into the console app so the data is stored in a SQL database. I have been researching for the past two days, and I found so many examples of how to create a repository service querying a local database, but I cannot see any decent example of how to integrate the data from external APIs to a local data storage solution, SQL database in my case.
Any information on how to structure services in a clean manner would help me a lot!
It basically boils down to the question whether you need to store locally data from a 3d party API. You are not the owner of that data.
In many cases it's better to query external API each time you need some data. You don't know if the data will change and when. E.g. you query each time weather data or currency convertion rate. External system knows how to produce such results, so ask the system each time. It's often ok to cache data from 3d party APIs, depending on the needs of your application (does your user needs weather updates with each refresh or once a day is enough, e.g. on a web site of a skiing area).
Now there can be cases when 3d party API is loosely coupled with your domain. E.g. you use a separate API to manage devices in a smart home solution. In this case we are talking about microservice architecture (Microservices by Fowler is a good start). It's OK in this case to build your local copy of the data from a 3d party API. Imaging your service is only interested in how often devices get replaced. So you may query device management API for broken devices and store this information locally in the form that is better for your application. You get data, reorganize it as it better fits you, store and use it.
So basically as always with such broad questions: it depends. On what are you building, on what external API provides, on what do you want to do with the data you query.
Going technical on your question: you query data e.g. via REST from a third party. This gets you TheirObjectDto. You process this data. Their object may change, you are not the owner of the contract. You create MyObject, which contains the data that you need. You save it to your DB (via repository, if you want). You build an Entity for it and DB table. When 3d party API changes and returns TheirObjectDto2 you still work with MyObject. Minimal change for you is to convert TheirObjectDto2 to MyObject. Your app continues working. In a second step if you want some new cool info of TheirObjectDto2 you modify your internal data structure.
How to integrate a WebSphere commerce application with third party website currency converter, the currency converter website return a wsdl file. How can I work, any help regarding this would be appreciated.
You have two methods.
Method 1. Overload the payment calculation CommandTask to call out the WSDL OR create a new CommandTask to call out the WSDL and append it to the Command process (latter is better because it doesn't change current process flow).
Method 2. Populate the currency table in WCS using WCS scheduled jobs.
Of the two and not knowing your requirements.... Method 2 has better performance because it is relatively static and WCS will automatically dynacache it.
See the process flow at http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.developer.doc/refs/rgxxref.htm
See the ERD at http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.data.doc/refs/rdmindex.htm
See the API at http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.api.doc/overview-summary.html
In all situations, I would recommend that you apply for the WCS business partner program. http://www-01.ibm.com/software/commerce/websphere-commerce/technology-partners/. Once you join IBM, they'll assign staff to provision an environment for you and help you with the 3rd party integration and maybe even publish a white paper together.
I'm planning to get GREG from WSO2 as business service registry. We're currently storing services in a Spreadsheet as a delimited text file. Services are still abstract concepts (operations not).
Which is the best approach (painless, programming-less...) to do a bulk load of about 660 business services and 12000 operations?
The most painless way probably is using the registry client. WSO2 provides a java based client you can use to easily access the registry. It won't be completely painless, but with a couple of lines of code you could easily add this information.
On other option would be to directly plug in to the underlying JCR repository or database, but than your entering the painful area I think.
This post http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes
encourages me to create the web service for business logic layer but many people use it in the data access layer.
I want to create a project where i want to access the same data repository from a desktop application, website and a cell phone. What would you recommend me?
Is there any case it may be a good idea to implement web services to both layers?
The question is too open ended so the answer is: it depends.
What needs do your applications have for the data? Is it just data access or some business logic involved? If it is just accessing of data, do you really want the client to have direct control over it? How similar are the three applications? Do they share functionality or just data?
As I see it there are two main paths you can chose:
1 - expose a web service for the business, with the data hidden behind the web service. This is a good setup if the three clients (I'll call the desktop app, web app and cell phone "clients" since that is what they are) share functionality (i.e. they are different views for the same business model). This avoids duplicating similar business logic in all the clients;
2 - expose the data directly with a web service. This is a good setup if the three clients have nothing in common but just use the same data for different purposes. But in this case, with the three sets of business logic, where are you going to put the logic? In the clients? How will that work for the desktop application (considering you install this desktop app 300 times or so)? You again need some service and the clients to be thin clients not thick ones.
If you take 1) and 2) into consideration you will see that usually it is better to have a service layer in front of your data.
Going back to the "it depends", analyze your special needs first and only then choose the solution that is best suited for your situation.
How about a point 3? make your data access layer into a library (.jar, .dll or whatever technology you are using) and make that available to the (1? 2? 3?) business web services that serve your clients?
I am tasked with creating an API that would allow 3rd party customers the ability to send orders into our Microsoft Dynamics NAV 5.0 SP1.
I want to be able to create a SalesOrder in Dynamics NAV not with the client but via an API so i can allow a seperate process to enter in orders automatically.
Any help is appreciated in leading me in the right direction.
Well, it depends on how complicated you want to make it. Do you need confirmation of the Sales Order creation in "real time"? If so, you'll need to use a Web Service and ensure that there is a network path from wherever customers will create orders (public internet, extranet) to your NAV Web Service - likely using a VPN tunnel, etc.
es th
Alternatively, if you can live with a batch type process then you can have your customers create SOs via a web-based form, etc. and then import these orders into NAV on a regular basis using Dataports or XMLPorts.
For example, you may have a form online that your customer can create an Order on that places the Order in a staging table in SQL or even an XML or CSV file. Then you can run a process on a regular basis that imports these Orders into NAV and creates the appropriate SalesOrders.
Presumably, you also need a way to expose your Item database to the Ordering interface so customers can select which Items to order (and therefore create SalesLines from).
Which type of scenario are you interested in?
Web Services is the way to go; we have several applications that have a similar requirement. I'd recommend building an interface (ASP, to utilise the web service from NAV) and have it talk to NAV that way.
Editing the database directly is not recommended as it will cause locking and may result in deadlocks if not careful. Also NAV can be quite sensitive when it comes to the database, so best not write to it directly if possible :)
I'd recommend creating a codeunit that handles the sales order, in which you can create your functions, 'CreateOrder' and then expose that via Web Services. Even if you're not planning to use a web-based interface, NAV uses the SOAP protocol -- many libraries exist to enable you to connect and interface to Web Services from other languages, like Java.= for instance.