| Author |
Message
|
| amateur10 |
 Posted: Fri Dec 02, 2005 8:20 am Post subject: Who is in control in ICS |
 |
|
Centurion
Joined: 23 Nov 2005
Posts: 102
|
When the ics systems is running who is in control ? I mean who manages which system tlo run first, what next etc
a sequences of steps starting from connector agent
thanks |
|
| Back to top |
|
 |
| kotha |
| Posted: Fri Dec 02, 2005 12:32 pm Post subject: |
|
|
Partisan
Joined: 12 Mar 2005
Posts: 333
|
| Quote: |
| I mean who manages which system tlo run first, what next etc |
The Collaobartion will take care of it. The sequence is as you defined in the scenario of the Collaboration. |
|
| Back to top |
|
|
| amateur10 |
| Posted: Mon Dec 05, 2005 8:55 am Post subject: |
|
|
Centurion
Joined: 23 Nov 2005
Posts: 102
|
Okey. But how it works?
can you please tell me about port and triggering BusObj? when we make a service call what happened and what bo variable to be assigned and why?
thanks |
|
| Back to top |
|
|
| kotha |
| Posted: Mon Dec 05, 2005 10:57 am Post subject: |
|
|
Partisan
Joined: 12 Mar 2005
Posts: 333
|
I have seen lot of posts from you.
Dont be confused. As a developer you dont need to dig deep for the details. The logic is simple and clear as explained below:
for example, let us take two systems. one is workflow system and the other is database. our intension is whenever workflow put a message into a MQ queue, the database should be updated with the fields in the message.
Now, assume a message is arrived to a queue, the MQWorkflow Connector takes the message and parse it and populate the BO and trigger the Collab.
with the assistance of mapsthe concerned BO for the database will be populated. then the Collab has a service call to database, and DBConnector will update/insert/delete the table based on the app specific info provided in the BO.
If you are learning the ICS, install the connectors and go through the connectors help documentation and try out the examples given in connector documentation. then experiment and play with the example. |
|
| Back to top |
|
|
| amateur10 |
| Posted: Mon Dec 05, 2005 12:02 pm Post subject: |
|
|
Centurion
Joined: 23 Nov 2005
Posts: 102
|
Thanks for suggestion and answer. I agree with you but I am trying to clarify something which is not found in literature( i mean documentation). If it is somewherhe in documentation, please refer me.
My main problem is now, when a ASBO enter the Collab, what happens and some thing about port and triggering events.
thanks |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Dec 05, 2005 12:23 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
The flow is:
1. The application has new data ( An event is signalled)
2. The connector agent polls for new events.
3. For a new event, connector agent with the help of data handlers converts the application data to ASBOs.
4. The ASBO is converted to GBO using MAP.
5. Map supplies GBO to the connector controller. Connector controller is residing in the ICS.
6. Collaboration Object that is subscribed to the GBOs are kicked off.
7. The business process inside the collaboration is executed.
A triggeredBusObj is the BO that is given to the collaboration object by the calling connector.
A collaboration can call an external system (for example another connector) using a service call only.
Now in this service call, you specify a business object and port.
The specified business object should have values populated in it.
For a pass thru collaboration you can specify the trigeeredBusObj in the service call.
8. The connector controller then hands off the GBO to the map.
Map converts the GBO to ASBO and then hands off to connector agent.
9. Connector agent converts the ASBO to application data using the specified datahandlers.
Some adapters don't need data handlers. For example JDBC adapter doesn't need data handler. |
|
| Back to top |
|
|
| amateur10 |
| Posted: Mon Dec 05, 2005 7:54 pm Post subject: Some clarification |
|
|
Centurion
Joined: 23 Nov 2005
Posts: 102
|
Thanks for the detailed and clear answer.
I am clear in the point 1-5 except one question.
what happened if the connector does not have associated map ? then the BO that enters into the Collab is ASBO right? collab has to run the map to convert that ASBO into GBO? How the triggeringBusObj get value from? what is subscribing a BO means? Is the Fom port a subscription?
As I understand, the port
From
To
ErroMSG etc has nothing to do except that ics creates a business object to PortnameBusObj. Is this true?
Thanks
Second, |
|
| Back to top |
|
|
| sdng |
| Posted: Tue Dec 06, 2005 2:55 am Post subject: |
|
|
Acolyte
Joined: 23 Nov 2005
Posts: 53
|
I dont agree with vennela
1-2 is right
but
then 3 agent check subscription for received asbo, if it is not exists agent generate error "no subscription"
then 3-7
if connector does not have associated map there is not subscription.
(You also can not bound collab to connector is it does not support this GBO)
all ports in collab use according to business logic. from,to,... - typical name for typical port roles. you can use others names.
also, colab does not run maps (in typical situation, you can run it manual only)
Any collab receive input BO into triggeringBusObj (ICS does it) than collab do something with it (usualy copy it into FromBusObj, ICS does not put input BO into FromBusObj. you can see it in "main" scenario in action "Initialize Variables")
subscription is when exists way from ASBO to Collab (ASBO->GBO, Connector supply ASBO and GBO and there is Collab with port with stated scenario for the event) imho
_________________
Are you gangsters? No, we are Russians! |
|
| Back to top |
|
|
| amateur10 |
| Posted: Tue Dec 06, 2005 8:16 am Post subject: |
|
|
Centurion
Joined: 23 Nov 2005
Posts: 102
|
thanks again. Let me put questions for clarification.
When I said collab run mean we explicitely run map. We can do that. this means we do not necessarily have to assigned map with connnector. But in this case, at the entry point, the GBO is blank. It gets value when the map is run. but
my question about port was that when we mentioned name of GBO associated with one port name, does that mean we are susbcribing or publishing ? is this right? but value to the publishing bo has to be populated manually right?
thanks |
|
| Back to top |
|
|
| recallsunny |
| Posted: Tue Dec 06, 2005 2:03 pm Post subject: |
|
|
Disciple
Joined: 15 Jun 2005
Posts: 163
Location: Massachusetts
|
To further clarify this discussion:
You can eliminate the need for a Map in the inbound connector, if you choose to pass the ASBO directly to the collaboration(in this case your Ports & Triggering tab should use ASBO when binding your scenarios for a particular Port).
Remember: When you bind a BO to a Port+scenario+Verb in collab, make sure that it has data in it. Ex: When not planning to use a Map in inbound connector, bind the ASBO directly to Collab. Similarly when planning to use a map ASBO->GBO, then bind the GBO in your collab.
Secondly, when you associate a Port to a scenario (with BO type), you are defining a trigger point for your scenario.
Lets say You've the following config (this is subcribing for this event):
Port (From) + BOtype (Customer) + Verb Create (Scenario: Register Emp).
When your inbound connector (From port) recieves a Event of Type "Customer" with verb "Create", the collaboration has already subscribed for this event, hence the event initiates the "Register Emp" scenario thus executing your process. If there is a service Call in your process, make sure that you populate the BO (either by a copy or internal map exec) which is associated with the service call. |
|
| Back to top |
|
|
| amateur10 |
| Posted: Tue Dec 06, 2005 2:19 pm Post subject: |
|
|
Centurion
Joined: 23 Nov 2005
Posts: 102
|
One more time. My next question was that the from port which we assign with a bo with data ( may be asbo or gbo based on situation) receibves data for the collab. but the uses of other port is
to create a Ojbect automatically by ics
to use while making services call
right
pls clarify
thanks |
|
| Back to top |
|
|
|
|
