App Connect

Hi Sumit, 
I have not actively worked on IIB10 for a few years now, and without an active running IIB 10 broker I cannot give you the exact steps, you would have to use the below as a guide to figure it out. But from memory this is what I would do. 
First do a mqsibackupbroker, https://www.ibm.com/docs/en/integration-bus/10.0.0?topic=commands-mqsibackupbroker-command , as it would not be a good idea to work server itself. The backup would generate a zip file that you should work with locally. 
Again all of this is from memory so might not be exact, you would need to look up the execution group guid name from the server as that would be the folder that would contain all flows deployed to that execution group, browse the zip file you looking for the folder matching that guid name and the deployed artefacts would be in there. 
This is the hard part, these artefacts could be compiled and in different folders (flow, xsd, esql, ect are sometimes separated) so chances are they might not just be a copy and paste, you might  have to build a whole new app from the what is in the folder as it does not "run" as "built". It all depends on if it was a standalone flow or an App and the way the bar was build.

This is possible but not a quick task and would require hands on to reverse what was compiled. 

Good Luck. 

You cannot retrieve the BAR file itself on IIB 10. BAR regeneration only exists in ACE. The good part is that you probably do not need it. The BAR is not what you are after, the flow is, and the flow is still on the broker in a readable XML format, just not as a .msgflow.

Every deployed artifact sits in this folder structure
<MQSI_WORKPATH>\components\<broker>\<egUUID>\config\<appUUID>\**

With the message flows here
<MQSI_WORKPATH>\components\<broker>\<egUUID>\config\<appUUID>\FLOWS\<flowUUID>\dataFlowManager.xml

If you open it in a text editor, you get the full message flow content. I checked this on 10.0.0.26 by deploying the same application twice, once as source and once with compile and in-line, and searching the whole work path. Both give me the same result (almost the same, except for the esql).

You might be tempted to think that a simple rename of the file would work, but that is not the case. For instance, the dataFlowManager.xml does not contain a canvas location, which a .msgflow file does have (it tells the toolkit where to display the nodes). A dataFlowManager.xml is a runtime file, not a toolkit file.

ESQL files are plain readable as well, in ..\config\<appUUID>\ESQL\, if you deployed without "compile-and-inline". If you deployed with "compile-and-inline", the esql becomes part of the dataFlowManager.xml. You can recover it from there, it is readable text, but that is an extra step for you to do.

Two things to watch out for 

1) The execution group labels are recorded as ExecGroupLabel in <MQSI_WORKPATH>\components\<broker>\repository\brokeraaeg.dat. But encoded in base64. Example: SVMx is not an EG called SVMx, it decodes to IS1.
2) An XML parser cannot help you pull ESQL out of a compiled dataFlowManager.xml. Normalization and parser interpretation can break the ESQL layout, so use a normal text editor, like Notepad++.

But this is poking around in your runtime, not always a good idea. Especially not if you are not familiar with it.

Tyron is right that you should start with mqsibackupbroker and work from the backup rather than poking at the running node. IBM documents that a backup includes your deployed resources, so nothing is lost by doing it that way.

For example

v10:
mqsibackupbroker TESTNODE_Matthias -d c:\temp\ -a backupBroker.zip
BIP1252I: Creating backup file 'c:\temp\backupBroker.zip' for integration node 'TESTNODE_Matthias'.
BIP8071I: Successful command completion.

v13:
ibmint extract node --backup-file c:\temp\backupBroker.zip --input-integration-node TESTNODE_Matthias --output-integration-node TESTNODE_13_Matthias
BIP8469I: Version '10.0' backup file supplied.
BIP8471I: Loading configuration for source integration node 'TESTNODE_Matthias'.
BIP8389W: Property 'sslProtocol' for the node wide httplistener 'HTTPSConnector' is no longer available. The property was configured with value 'TLS', which was not the default.
BIP8470I: Loading configuration for integration server 'EG_CMF'.
BIP8470I: Loading configuration for integration server 'EG_SRC'.
BIP8470I: Loading configuration for integration server 'default'.
BIP8473I: Creating target integration node 'TESTNODE_13_Matthias'.
BIP15288W: Component 'JVM' is not required by the current contents of this integration server;  therefore the Java specification will have no effect.
BIP15288W: Component 'JVM' is not required by the current contents of this integration server;  therefore the Java specification will have no effect.

This will give you a v13 runtime with your application deployed, unless there are a couple of unsupported features in your flow.

(The reason my flows didn't start is that they use HTTP ports that are already in use)

The next step is retrieving the resources via the toolkit

This should give you your entire application.

I am not sure about all the node properties. I know retrieving resources (what we just did in v13) does not retrieve the broker.xml where any overridden properties live. I did a quick test on 1 property, and that did persist, but it's worth checking them nonetheless.

One thing that genuinely does not come back: Java. Only the compiled JAR ever reaches the broker, so if there is a JavaCompute node in there, you are out of luck.