Index Changes

Difference between version and version     

Back to Integration Flow Language Sample Scenarios, or Integration Flow Language Sample Scenarios Info


At line 3 added 2 lines.
Some examples from simple to complex to show how different scenarios can be expressed in IFL.
At line 7 added 55 lines.
!{{{File -> File}}}
{{{
file "infile"
file "outfile"
route from "infile" to "outfile"
}}}
!{{{File -> filter (removes entries) -> File}}}
{{{
file "infile"
file "outfile"
route do
from "infile"
to "filter"
to "outfile"
end
}}}
!{{{File -> transform -> File}}}
Note same as filter scenario, filter logic itself decides
{{{
file "infile"
file "outfile"
route do
from "infile"
to "filter"
to "outfile"
end
}}}
!{{{RSS BC -> request filter -> broadcast -> XMPP BC
-> File BC}}}
{{{
rss "myFeed"
jruby "filterFeed"
xmpp "notifyMe"
file "archive"
route do
from "myFeed"
to "filterFeed"
broadcast do
route to "notifyMe"
route to "archive"
end
end
}}}
!!Other Scenarios Where We Need to Add ArcheTypes to the Technology Preview
__Listed here for understanding and discussion purposes, these are not yet tested or supported__
At line 8 changed 2 lines.
SOAP "SOAPEndpoint"
BPEL "RecPartnerLink"
soap "SOAPEndpoint"
bpel "RecPartnerLink"
At line 22 changed 1 line.
<-}}}
<-}}}
At line 24 changed 1 line.
{{{
At line 83 added 1 line.
}}}
At line 85 added 1 line.
!{{{HTTP BC -> transform -> BPEL (in-only)}}}
At line 28 changed 2 lines.
HTTP BC -> transform -> BPEL (in-only)
{{{
At line 35 changed 1 line.
}}}
At line 95 added 1 line.
{{{
At line 101 added 1 line.
}}}
At line 103 added 2 lines.
!{{{HTTP BC -> request transform -> BPEL (in-out)
<- response transform <-}}}
At line 44 changed 5 lines.
(should this be called a filter or is it confusing that it transforms? Should there be a "sequence" construct?)
HTTP BC -> request transform -> BPEL (in-out)
<- response transform <-
{{{
At line 112 added 1 line.
}}}
At line 56 changed 4 lines.
HTTP BC -> BPEL (in-out) -> EE Webservice (in-only)
<- -> HTTP BC (in-out)
<-
!{{{HTTP BC -> BPEL (in-out) -> EE Webservice (in-only)
<- -> HTTP BC (in-out)
<-}}}
{{{
At line 124 added 1 line.
}}}
At line 126 added 5 lines.
!{{{HTTP BC -> sequence -> CICS BC (in-out)
<- | <-
| -> JDBC BC (in-only)
| -> HTTP BC (in-out)
<- <-}}}
At line 67 changed 6 lines.
HTTP BC -> sequence -> CICS BC (in-out)
<- | <-
| -> JDBC BC (in-only)
| -> HTTP BC (in-out)
<- <-
{{{
At line 139 added 3 lines.
}}}
* For "to" with in-out the rule would be the output is linked to the next input if it's not at the end
* For "to" with in-only the rule would be that the last relevant input remains valid.
At line 80 changed 2 lines.
For "to" with in-out the rule would be the output is linked to the next input if it's not at the end
For "to" with in-only the rule could be that the last relevant input remains valid?
!{{{HTTP BC -> JDBC BC (in-only, but operations don't match)}}}
At line 145 added 1 line.
For this the explicit operations support needs to be added.
At line 84 changed 98 lines.
(overload to for final service as well as filter?)
RSS BC -> request filter -> broadcast -> request transform -> XMPP BC (implicit operation / operations match)
-> AjaxPush BC
route do
from "myFeed"
to "rubyFilter"
broadcast do
branch do
to "transform"
to "notifyMe"
end
branch to "publisMe"
end
end
(? How does it actually remove messages in this "filter"? Does it need a separate construct for interceptors from true filtering?)
Possible alternative with explicit "filter". Danger: filter here really means removing stuff, not really "pipe and filter"
route do
from "myFeed"
filter "rubyFilter"
broadcast do
branch do
to "transform"
to "notifyMe"
end
branch to "publisMe"
end
end
alternate definition?
route do
from "myFeed"
filter "rubyFilter"
broadcast do
branch "transformAndNotify"
branch to "publisMe"
end
end
def "transformAndNotify" do
to "transform"
to "notifyMe"
end
Demo scenario (slightly simpler than above, not transform in broadcast)
RSS BC -> request filter -> broadcast -> XMPP BC (implicit operation / operations match)
-> AjaxPush BC
3 equivalent variants
RSS "myRSS"
JRuby "filterFeed"
XMPP "notifyMe"
AjaxPush "displayOnPage"
route do
from "myRSS.processFeed"
to "filterFeed.filter"
broadcast do
branch to "notifyMe.sendIM"
branch to "displayOnPage.push"
end
end
variant 2:
route do
from RSS "myRSS.processFeed"
to JRuby "filterFeed.filter"
broadcast do
branch to XMPP "notifyMe.sendIM"
branch to AjaxPush "displayOnPage.push"
end
end
and again variant 3 with pre-defined services
route do
from "myRSS.processFeed"
to "filterFeed.filter"
broadcast do
branch to "notifyMe.sendIM"
branch to "displayOnPage.push"
end
end
HTTP BC -> JDBC BC (in-only, but operations don't match)
{{{
At line 189 changed 29 lines.
or let's say only few operations don't match - default and override?
route from "SOAPEndpoint" to "JDBCOneWay"
route from "SOAPEndpoint.operation1" to "JDBCOneWay.updateCustomer"
or should we consider an explicit mapping construct? Could default to using "as is" if not mapping defined.
route do
from "SOAPEndpoint"
map_operation (operation1=insertCustomer, operation2=updateCustomer)
to "JDBCOneWay"
end
HTTP BC -> Dynamic Router
(as usual, artifact type "DynamicRouter" is optional
route from "SOAPEndpoint" to DynamicRouter "myRouter"
How do we just "publish" target endpoints that can by dynamically called. Something like?
route From "LocalCandidateEndpoint1"
route from "LocalCandidateEndpoint2"
(? Should it actually allow defining some of the candidate endpoints here? Dynamic routing rules only defined outside of the language, e.g. in a DB?)
}}}

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-7) was last changed on 04-May-08 18:12 PM, -0700 by AndiEgloff