Hi! Our Team is interested in integrating Ariba with our PPM tool. We were wondering if there are any materials available to learn more about the integration or best practices/lessons learned about this. Thanks!
The integration of data into Clarity can only be done through the supported XML interface (XOG) - there is a dedicated manual for this "XML Open Gateway Developer Guide" - look for that against the document set for your Clarity version. XOG is supported for on-premise and on-demand models.
Getting data out of Clarity can also be done via XOG but may also be read via SQL direct to the database if you are happy doing that and your database is on-premise. (you would not be able to do this on-demand)
As Dave states, “XML Open Gateway Developer Guide” is the definite place to start for learning on the Clarity API.
As for best practice, here is what I do. There are three main XOG web services: Object, Query and InvokeAction and my best practices:
I use the Object web service to create / update (sometimes delete) objects in the system. On each object type, have a field (or way to identify a newly created object) because the Object web service doesn’t return any information (other than success / failure / count) about newly created objects (this assuming you want to create objects with auto numbering). If not auto numbering you need to supply the ID which gives you the way to identify. In my case the customers like the consistent numbering sequence.
I use the Query web service (over the Object read) as each NSQL is available via the Query web service so create a set of interface specific queries. With NSQL, you can return complex record sets, multiple object types or the single object with the ability to filter / sort / limit. In addition since the NSQL defines only the necessary data being returned, the xml response payload can be much smaller over an object read response payload.
I use the InvokeAction web service to preform heavy lift actions on the server. For example, say you have a need to create a new project, then create a number of custom objects associate to the project, populate fields on each of the objects created and then assign some resources. If these actions were wrapped up in a process then the interface just passes in the required parameters for the process and goes along it merry way. I also like this way because the interface doesn’t need to be cracked open if a PPM configuration change (say some newly created object fields need some existing date from other object field values). Here you just update the PPM process and the interface doesn’t care.
Also a couple of things that just remembered:
In .NET, it is simpler to use ASMX over WCF web services for access the APIs if you are just getting started.
I use SOAPUI to test all my NSQL Queries before trying to figure out why they are working right in my code.
When pulling back a large number of nodes via an Object reads you may not get all the objects (and no way to tell if you did get all the objects) depending on the configuration setting for xog limits.
Retrieving data ...