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.
Related
actually I am working with PDI 8.2, however I am able to upgrade to 9.0.
The main issue is that a customer wants to pull data from salesforce which works well so far. But he is using the Enterprise Web Services API with version 48.0, latest Pentaho supports v47.0 only.
I strongly assume that reading via v48.0 won't work with PDI so that I have to build a workaround. Could anyone point me to a feasible solution? To be honest, I don't even know whether the Enterprise or the Partner API is relevant for Pentaho. Have got my own SF-Account so that I could try around with the APIs.
Is the "Web Services lookup" the right step for the workaround?
Any answer would be appreciated! Thanks in advance!
Oh man, what a crazy question, all over the place.
I strongly assume that reading via v48.0 won't work
You'd have to try it but it should work. Salesforce has 3 releases a year and that's when they upgrade API versions. We're in Spring'20 now, it's v.48. That doesn't mean anything below is deprecated. You should have no problems calling with any API version >= 20. From what I remember their master service agreement states that API version released will stay up at least 3 years. Well, v.20 is 9 years old and still going strong...
Check for example https://baa.my.salesforce.com/services/data/ (if your client has "My Domain" enabled you can use that too instead of some unknown company), you should see a list similar to this: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_versions.htm (no login required, that'd be a chicken & egg situation. You need to choose API version you want when making the login call).
So... what does your integration do. I assume it reads or writes to SF tables (objects), pretty basic stuff. In that sense the 47 vs 48 won't matter much. You should still see Accounts, Contacts, custom objects... You won't see tables created specifically in v 48. Unless you must see something mentioned in Spring'20 release notes I wouldn't worry too much.
If your client wrote a specific class (service) to present you with data and it's written in v.48 it might not be visible when you login as v.47. But then they can just downgrade the version and all should be well. Such custom services are rarely usable by generic ETL tools anyway so it'd be a concern only if you do custom coding.
whether the Enterprise or the Partner API is relevant for Pentaho
Sounds like your ETL tool uses SOAP API. Salesforce offers 2 versions of the WSDL file with service definitions.
"Partner" is generic, all SF orgs in the world produce same WSDL file. It doesn't contain any concrete info about tables, columns, custom services written on top of vanilla salesforce. But it does contain info how to call login() or run a "describe" that gives you all tables your user can see, what are their names, what are columns, data types... So you learn stuff at runtime. "Partner" is great when you're building a generic reusable app that can connect to any SF or you want to be dynamic (some backup tool that learns columns every day and can handle changes without problems. Or there's a "connection wizard" where you specify which tables, which columns, what mapping... new field comes in - just rerun the wizard).
"Enterprise" will be specific to this particular customer. It contains everything "Partner" has but will also have description of current state of database tables etc. So you don't have to call "describe", you already have everything on the plate. You can use this to "consume" the WSDL file, generate your Java/PHP/C# classes out of it and interact with them in your program like any other normal object instead of crafting XML messages.
The downside is that if new field or new table is added - you won't know if your program doesn't call "describes". You'd need to generate fresh WSDL and consume it again and recompile your program...
Picking right one really depends what you need to do. ETL tools I've met generally are fine with "partner".
Is the "Web Services lookup" the right step
No idea, I've used Informatica, Azure Data Factory, Jitterbit, Talend... but no idea about this Pentaho thing. Just try it. If you pull data straight from SF tables without invoking any custom code (you can think of SF custom services like pulling data from stored procedures) - API version shouldn't matter that much. If you go < 41.0 I believe you won't see Individual object for example but I doubt you need to be on so much cutting edge.
I want to create a weather app for my android phone but now I got stuck on the backend part of the app.
I have found a weatherservice where I can, for free, get detailed information about a certain location through their webservice. But they have stated in their rules that I am not allowed to poll their service with a high frequency. So I thought that I could create a webservice on my own that retrieve weatherinformation from the weatherstation that I found and then make it available through my webservice so that my app only make calls to my service.
the communication will be like below
MyApp <--> MyWebService <--> commercial webservice
the android app talks to MyWebService. And my webservice talks to the commercial service.
So I want MyWebService to do to things.
retrieve information from the commercial webservice once every hour and update my database
handle requests from my androidApp
My problem is that I know to little about web application and web services. I don't really know what language to choose for the webservice.
PHP with soap or REST looks like a good candidate for the second task. But I can't find any sample on how to handle the first task. Is there any easy way to tell the server to run my script once every hour?
I have been looking a litle into C# as well which would suit me a litle bit more as I am more used to C#. But the same question arise here. How do I handle the second task?
This is something that I wanted to write for a long time, but I feel totaly lost here.
Doing things "once an hour" (or more generally, scheduling tasks) from a web-only application is tricky for a number of reasons. It is much better in general to use the built-in mechanism of the operating system to perform scheduled tasks (e.g. cron under Linux, or Scheduled Tasks under Windows), or to write a service/daemon process that handles the updates.
Having said that, there is a fairly straightforward way to meet your requirement. You can cache the result of the commercial web service in your web application tier, along with a timestamp of the last time you retrieved the information. When a web request comes into your web service from your app, first check the timestamp of the cache. If the timestamp is less than one hour old, just returned the cached weather data. If the timestamp is more than an hour, call the commercial web service directly from there, write the result and the current time into your cache, and return the data you just got to the app.
PHP is certainly well-suited to this kind of task. Detailed instructions on how to do that are beyond the scope of a Stack Overflow question. Google for PHP and caching, try out some examples, and ask detailed follow-up questions if you get stuck.
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.
Nowadays a lot of web applications are providing API for other applications to use.
I am new to the usage of API so I want to understand the use cases for it.
Lets take Basecamp as an example.
What are the use cases for using their API in my web application?
For inserting current data in my web application into a newly created Basecamp account instead of inserting everything manually which could take days or weeks if the data is huge?
For updating my application data when the user changes something in Basecamp. If so, how do I know for example when a user add/edit/remove a contact in Basecamp. Do I make a request and check every minute from the backend?
For making backup of the Basecamp data so I can move it to other applications if necessary?
Are all the above examples good use cases for the usage of API?
Are there more use cases?
I want to have a clear picture of why it's good to use another web service API and how I can leverage that on my application.
Thanks.
I've found the biggest reason to use and provide web services is to be able to programmatically drive the application with another process. This allows the coupling of different actions in different applications driven by one event/process/trigger.
For example I could create a use a webservice provided by Basecamp, my bug tracking database and the continuous integration server. I could tie all those things together and kick them off from a commit hook script.
I can have a monitor in production automatically open a ticket in our ticket tracker. This could trigger an autoremediation process from the ticket tracker which logs into the box remotely and restarts the service.
The other major reason I've seen to use and provide web service is to reduce double entry. If you do change management in your production environment that usually means you create Change tickets. The changes that occur may also need to be reflected in the Change Management Database which is usually a model of how production is suppose to look. Most of these systems don't automatically drive the update of your configuration item with the data from the change. Using web services you can stitch them together to eliminate the double (manual) entry that would normally occur.
APIs are used any time you want to get data to/from an application without using the default interface.
*I'd bet there's a mobile app would use the basecamp api.
*You could use the api to pull information from basecamp into another application (like project manager software or an individual's todo webpage)
*the geekiest of us may prefer to update basecamp from a script/command line rather than interrupting our work flow to open a web page and click around.
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.