11. The method of claim 1 , further comprises of— a) Capturing a request for executing said KBM workflow, when an online or batch request is made by the end user, and recording it in a queue called KBM Workflow queue; Said request comprises of name of workflow and information regarding the key fields of the entities that participate in the processing of the workflow; b) Retrieving the request for executing the Workflow from the said KBM Workflow Queue, by KBM WorkFlow Coordinator, supplied as part of KBM runtime, and tools, which schedules and controls the execution of KBM Workflows; c) Retrieving the Workflow specification document, based on the workflow name received as input in the said KBM Workflow queue record; d) Parsing said Workflow document, and identifying the activity blocks, which are scheduled for execution; e) Scheduling the activity contained in the next block for execution if said block is enclosed in special tags called “SEQ”, which imply that the activity is to be executed in sequential order, by creating an instance of the activity module to be executed, and executing the “init” method, and subsequently the “execute” method, and creating a record in a table called KBM WorkFlow Execution status table, indicating that the activity was scheduled for execution; f) Scheduling all the activities contained in the next block for execution if said block is enclosed in special tags called “CONCUR”, which imply that the activities are to be executed in concurrent order, by repeating the process described for said single activity delimited by “SEQ” tags, for each of the activities specified in the block, delimited by the “CONCUR” tags; g) Executing the process structures of lower order contained in the current process structure recursively, by executing their init, execute and finish methods, until the current activity being executed, reaches a desired or special state; h) Updating said KBM Workflow Execution status table, when activities scheduled by workflow coordinator for the said KBM Workflow, have reached a desired or special state; i) Monitoring the Execution status of the activities already scheduled for execution by the said KBM Workflow coordinator, based on a preset timer; j) Scheduling the next workflow block of the current workflow for execution, if all the activities of the current workflow block have reached a desired state; k) Updating said KBM Workflow Execution status table, with the completion status of the workflow, when all activities scheduled by workflow coordinator for the said KBM Workflow, have reached a completion state.
11. The method of claim 1 , further comprises of— a) Capturing a request for executing said KBM workflow, when an online or batch request is made by the end user, and recording it in a queue called KBM Workflow queue; Said request comprises of name of workflow and information regarding the key fields of the entities that participate in the processing of the workflow; b) Retrieving the request for executing the Workflow from the said KBM Workflow Queue, by KBM WorkFlow Coordinator, supplied as part of KBM runtime, and tools, which schedules and controls the execution of KBM Workflows; c) Retrieving the Workflow specification document, based on the workflow name received as input in the said KBM Workflow queue record; d) Parsing said Workflow document, and identifying the activity blocks, which are scheduled for execution; e) Scheduling the activity contained in the next block for execution if said block is enclosed in special tags called “SEQ”, which imply that the activity is to be executed in sequential order, by creating an instance of the activity module to be executed, and executing the “init” method, and subsequently the “execute” method, and creating a record in a table called KBM WorkFlow Execution status table, indicating that the activity was scheduled for execution; f) Scheduling all the activities contained in the next block for execution if said block is enclosed in special tags called “CONCUR”, which imply that the activities are to be executed in concurrent order, by repeating the process described for said single activity delimited by “SEQ” tags, for each of the activities specified in the block, delimited by the “CONCUR” tags; g) Executing the process structures of lower order contained in the current process structure recursively, by executing their init, execute and finish methods, until the current activity being executed, reaches a desired or special state; h) Updating said KBM Workflow Execution status table, when activities scheduled by workflow coordinator for the said KBM Workflow, have reached a desired or special state; i) Monitoring the Execution status of the activities already scheduled for execution by the said KBM Workflow coordinator, based on a preset timer; j) Scheduling the next workflow block of the current workflow for execution, if all the activities of the current workflow block have reached a desired state; k) Updating said KBM Workflow Execution status table, with the completion status of the workflow, when all activities scheduled by workflow coordinator for the said KBM Workflow, have reached a completion state. 12. The method of claim 11 , further comprises of— a) Generating a record called Activity Failure record, for each of the activities of the current workflow block, which have reached a special state, and writing the said Activity Failure record to a queue specified for the special state of the activity, in the activity configuration file; b) Said Activity failure record is the result of failure of a KBM Gear of the failed activity, and is derived from an object called Gear Failure record, which is generated by a KBM gear of said activity when it has failed, and reached a special state, and when that special state reached is not connected to another KBM gear, but is handled by the activity, which is the container for the said failed KBM Gear; c) Rescheduling the activity, which has reached a special state, and which was marked as “resched with mp-color”, by the user module, executed to handle the special state.