Parse the XML content received from webservice SOAP response

[shubham5957]

I want to retrieve the content(like name, manager, project etc...) of the webservice response received through SOAP API and map to a custom table that will get updated on weekly basics.

[Dave Smith1]

but for that I have to convert it into CSV and then use the script to get the data from XML. 

That shouldn't be necessary.   Have you looked at Chuck's suggestion about SOAP import sets?   You should be able to do a field mapping transformation that way.

[shubham5957]

but the point is how you will get the data from XML and then automate it on weekly basics. I guess i have to run a schedule job that will parse the data from XML and insert it into custom table and then i can import it into target table. and moreover it is asking to create a web service and I am already consuming a web service for a third party app.

[Dave Smith1]

but the point is how you will get the data from XML 

SOAP import sets and transformation maps...?

and then automate it on weekly basics.

.. "scheduled imports"...?

The tools are already there, but you seem fixated upon rolling your own - which is why I asked if you'd already looked at Chuck's suggestion, but you didn't answer that question.

[shubham5957]

I read what chuck said in his comment but it is not fullfilling my requirements as in the web import set i have to manually upload the XMl file.. my job is to call the webservice using schedule job pull the data from that webservice response and put it into the target table.

[Dave Smith1]

i have to manually upload the XMl file.. 

Doesn't that defeat the purpose of the data being available as a web service?   You should be able to specify the web service as an import source and pull it straight in from there.

my job is to call the webservice using schedule job pull the data from that webservice response and put it into the target table.

I thought have thought your job was to:

1. create an import Data Source that connects to the web service and pulls data in
2. create a Transform Map that maps imported data to the final target table
3. use Scheduled Imports to have this run at a regular frequency.

The functionality is there, but you seem fixated on building your own method using scripts and XML to CSV conversions.

To get to your destination, I've suggested taking a taxi to the bus stop to catch a bus that will transport you to the train station where the remainder of your trip can be done by rail. But you're still talking about the design and construction of a bike specifically for this purpose.

Pick the easiest path, don't try to reinvent the wheel.   Your job should be concerned with achieving outcomes, not getting distracted with exploring custom methodology.

Any scripting approach brings an additional maintenance overhead, and I've encountered plenty of situations - both in and out of the SN platform - where people have ignored available toolsets and hacked out their own buggy undocumented solution.   In some cases it's taken me an hour to try and decypher what they've done, then 5 minutes scrubbing it and replacing it with a simple condition that detects a particular record situation and initiates a workflow, because that's pretty much what their code did but I'm willing to bet they spent a great deal more time overcomplicating the problem.