Retrieve XML of objects

What do you mean with "automatically"? What is the use case?

I need to retrieve the XMLs of objects and parse through the xml to get certain key value pairs of the default test cases which I need to use in the process model.

The only way I am aware of to get the XML is by exporting an application or package.

I am interested in more detail in your use case? You mention key value pairs and test cases. What do you want to achieve?

We want to get those values and save them in DB and then use them in a rule in a process model where we can piece the name, parameters together and call the integrations using the eval function and retrieve the statusCode and see if the integration health is working without any errors or not.

We wanna automate the process of retrieving those XMLs of the integrations so we can directly save them into DB without the manual activity of having to enter the integration names, parameters and save them to DB.

That seems to be a very wild concept. An hearing "eval" does not make it any better.

Is this about trying to monitor the integrated systems?

Yeah, exactly that.

I strongly recommend to leave monitoring of any systems to software made for this specific use case. I tried that several times and Appian is just no good choice for this.

I think you'd be better off building a separate Integration that conducts a "heartbeat" call to the remote system, which doesn't change the state of the remote system but can raise an alert if the remote system cannot be contacted.

hm alright, thanks.

We are doing heartbeat calls only. We just need a way to collect the names of all integrations across the environment so we can call them in the process.

Perhaps you can use either a!startRuleTestsApplications() or a!startRuleTestsAll(), and for every Integration you have an Expression rule that invokes that integration, and which has the relevant heartbeat information as a Test Case. You'd have to remember to create this kind of stub Expression Rule for every Integration but you could consider that to be best practice anyway. The unfortunate side-effect is that EVERY Test Case in EVERY Expression would also get invoked. Depending ion the volume of test cases and how often you want to heartbeat your remote systems this may not be a scalable option.

The alternative is to create a custom framework (a process model) that would run as often as you wanted to heartbeat your remote systems and explicitly include the integrations you want to flex - that is, a static implementation, rather than the dynamic one you were hoping to implement. 

Perhaps you can use either a!startRuleTestsApplications() or a!startRuleTestsAll(), and for every Integration you have an Expression rule that invokes that integration, and which has the relevant heartbeat information as a Test Case. You'd have to remember to create this kind of stub Expression Rule for every Integration but you could consider that to be best practice anyway. The unfortunate side-effect is that EVERY Test Case in EVERY Expression would also get invoked. Depending ion the volume of test cases and how often you want to heartbeat your remote systems this may not be a scalable option.

The alternative is to create a custom framework (a process model) that would run as often as you wanted to heartbeat your remote systems and explicitly include the integrations you want to flex - that is, a static implementation, rather than the dynamic one you were hoping to implement. 

Do you mean explicitly call the individual expressions or integrations in the process model?

Yes, that's what I mean by my second option. I recognize it's a maintenance overhead (you'd have to add a new Expression Rule wrapper for each new Integration, and add that ER to the process model. You would then get exactly what you want (in terms of a specific Integration heartbeating capability).

We are already trying to implement something like this. Thanks for the suggestion though.