anggi01

CA PPM On-Demand in a three layers architecture

Blog Post created by anggi01 Employee on Dec 7, 2017

The client is NEXI, a primary service provider for banking (credit cards processing)

 

The client is being using CA PPM, still on14.3, on-demand since 2 years ago.

 

Key processes so far implemented are demand and project management, a more mature resource and portfolio management is planned for the next year.

 

We are currently replacing a tool which has been used to let NEXI communicate with Equens, which is its first services provider and outsourcer for all the infrastructure of the client, to integrate the data about incidents and change requests.

 

With CA PPM we are in charge of the change request process, for which a change request is sent to Equens, to get an estimate first and then agree on costs and time and finally have the change implemented by Equens.

 

We have then a two-directions dialogue:

 

NEXI to Equens:

  • CA PPM sends the request for the estimate
    • the call is integrated as an action in the CA PPM workflow,
    • the call is based on gel scripts which reads a table of parameters, and fill an XML file which is then used to send the request to the SOA mid-layer. any call is traced in a custom object, in order to track everything about the dialogue.
  •    Then the SOA mid-layer intercepts the call and translate it into a web service call to Equens environment
  • Equens answers with a return code, which is passed back to CA PPM and stored as a result in the change data

 

Equens to NEXI:

it's basically the same route, with a difference: the call from SOA to CA PPM is basically the creation of a custom object via a standard customObjectInstance write. We then have a new instance of a custom object which is filled with the data received from Equens, and a CA PPM processes (triggered at creation) reads the data and populate the referring change.

In a more technical perspective, we then have:

  • a custom object to track the calls from CA PPM to Equens, which stores all of the data of the input change in the moment when the call occurred plus the XML used to call the web service. this for debugging purposes, and to be able to re-send the call in any moment (say that a service in the layer is down, we can re-send everything without triggering the change process
  • a custom object to receive the calls from Equens (it's basically an XOG call), which is processed in CA PPM by a common process,with an auto start on creation, which populated the data in the referring change. this solution enables: the usage of an OOTB web service call from outside, the track hat of every call that we receive.

Outcomes