Fix exit-forward when exit was never explicitly defined

[lenardvandermaas]

there was a bug in the xsl where exits were deleted if they weren't explicitly forwarded to. I removed the bit of code that removes such exits

[lenardvandermaas]

this is a very small and easy change, so maybe it's an idea to also implement it in older versions so that more people can use it

[mhdirkse]

This is about the XSLT that converts adapter XMLs to Mermaid syntax. That Mermaid text is used to draw flowchart pictures of adapters.

Jaco asked me to do a test on Lenard's fix. Please do not merge before I have my test result.

[mhdirkse]

This fix does not work for the following erroneous adapter XML. The error in the adapter is that the last forward points to a non-existent exit.

	<Adapter name="Update temperature">
		<Receiver name="Update temperature" flow:y="100" flow:x="100">
			<JavaListener name="Update temperature" />
		</Receiver>
		<Receiver name="ApiListenerReceiver" flow:y="250" flow:x="100">
			<ApiListener name="ApiListener" uriPattern="temp" />
		</Receiver>
		<Pipeline>
			<Exits>
				<Exit name="error" state="ERROR" code="500" flow:y="400" flow:x="1150" />
			</Exits>
			<SenderPipe
				name="Get temperature from OpenWeather"
				flow:y="100"
				flow:x="450"
			>
				<!-- <HttpSender
				url="http://api.openweathermap.org/data/2.5/weather?q=Amsterdam&amp;units=metric&amp;mode=xml&amp;appid=fd7031d5e258629ce81b0cffff3678c5"
                                                           /> -->
				<HttpSender>
					<Param name="url"
						value="http://api.openweathermap.org/data/2.5/weather?q=Amsterdam&amp;units=metric&amp;mode=xml&amp;appid=fd7031d5e258629ce81b0cffff3678c5" />
				</HttpSender>
				<Forward name="error" path="ERROR" />
			</SenderPipe>
		</Pipeline>
	</Adapter>

The mermaid produced is:

flowchart
	d202e2("<b>Update temperature</b><br/>JavaListener"):::normal
	d202e4("<b>ApiListenerReceiver</b><br/>ApiListener"):::normal
	d202e9("<b>Get temperature from OpenWeather</b><br/>SenderPipe"):::normal
	d202e8("<b>success</b>"):::normal
	classDef normal fill:#fff,stroke-width:4px,stroke:#8bc34a;
	classDef errorOutline fill:#fff,stroke-width:4px,stroke:#ec4758;
	d202e2 --> |success| d202e9
	d202e4 --> |success| d202e9
	d202e9 --> |error| 
	d202e9 --> |success| d202e8
	linkStyle 0,1,2,3 stroke:#8bc34a,stroke-width:3px,fill:none;

and you see a bomb instead of a Mermaid picture.

[mhdirkse]

With the error corrected it also fails. XML is:

	<Adapter name="Update temperature">
		<Receiver name="Update temperature" flow:y="100" flow:x="100">
			<JavaListener name="Update temperature" />
		</Receiver>
		<Receiver name="ApiListenerReceiver" flow:y="250" flow:x="100">
			<ApiListener name="ApiListener" uriPattern="temp" />
		</Receiver>
		<Pipeline>
			<Exits>
				<Exit name="error" state="ERROR" code="500" flow:y="400" flow:x="1150" />
			</Exits>
			<SenderPipe
				name="Get temperature from OpenWeather"
				flow:y="100"
				flow:x="450"
			>
				<!-- <HttpSender
				url="http://api.openweathermap.org/data/2.5/weather?q=Amsterdam&amp;units=metric&amp;mode=xml&amp;appid=fd7031d5e258629ce81b0cffff3678c5"
                                                           /> -->
				<HttpSender>
					<Param name="url"
						value="http://api.openweathermap.org/data/2.5/weather?q=Amsterdam&amp;units=metric&amp;mode=xml&amp;appid=fd7031d5e258629ce81b0cffff3678c5" />
				</HttpSender>
				<Forward name="error" path="error" />
			</SenderPipe>
		</Pipeline>
	</Adapter>

flowchart
	d202e2("<b>Update temperature</b><br/>JavaListener"):::normal
	d202e4("<b>ApiListenerReceiver</b><br/>ApiListener"):::normal
	d202e9("<b>Get temperature from OpenWeather</b><br/>SenderPipe"):::normal
	d202e8("<b>ERROR</b><br/>500"):::normal
	classDef normal fill:#fff,stroke-width:4px,stroke:#8bc34a;
	classDef errorOutline fill:#fff,stroke-width:4px,stroke:#ec4758;
	d202e2 --> |success| d202e9
	d202e4 --> |success| d202e9
	d202e9 --> |error| d202e8
	d202e9 --> |success| 
	linkStyle 0,1,2,3 stroke:#8bc34a,stroke-width:3px,fill:none;

[lenardvandermaas]

Now the success exit is also created in case there is an error exit defined, but no success exit. This should prevent any edge cases and all correct configurations should render a correct mermaid image

[mhdirkse]

De logica met exits werkt. Ik heb het getest.

[mhdirkse]

Ik heb ook getest met input/output wrapper/validator. Die lijken ook te werken, maar klopt de volgorde?

[mhdirkse]

[mhdirkse]

InputWrapper en InputValidator verschijnen vóór de eerste pipe, InputValidator eerst en daarna InputWrapper. OutputWrapper komt direct vóór de exit, ook als staat hij in de XML aan het begin.

[mhdirkse]

De OutputWrapper en de OutputValidator komen allebei aan het eind, in die volgorde.

[mhdirkse]

Ik voeg nog even mijn testresultaten met exits toe. Dan kunnen jullie controleren dat ik dit goed heb getest.

Defined         || Referenced      ||
success | error || success | error || Result
--------------------------------------------
yes     | yes   || yes     | yes   || yes
no      | no    || yes     | yes   || no
no      | yes   || yes     | yes   || no
no      | yes   || no      | yes   || yes, implicit success shown
yes     | no    || yes     | no    || yes, no implicit error shown
no      | no    || no      | no    || yes, implicit success and no implicit error

[mhdirkse]

Als er onder Result "no" staat, dan betekent dat dat er een Mermaid bom was. Dit gebeurt als er niet-bestaande exits expliciet worden gerefereerd. Geen probleem denk ik.

[nielsm5]

Reference in new

De juiste volgorde is:

• InputValidator
• InputWrapper
• Pipeline
• OutputWrapper
• OutputValidator

Deze volgorde wordt altijd zo uitgevoerd, ongeacht de volgorde zoals die in de xml gedefinieerd is.

[mhdirkse]

Hallo Niels. Jouw lijstje is wat de figuren tonen. Dit is dus in orde.