Creating PO Approval Workflow Demo Application

In this demo the web client application sends a request for Purchase Order Approval to the Infologica Web Services and further just queries the PO Status using the ticket issued by Infologica Fusion middleware.
On the server site the PO Approval request is handled by the Infologica Workflow Management Service. Triggered by the SOAP Listener the Infologica Workflow Engine creates the new instance of the PO approval workflow and invokes the first activity which sends SMS message to the nominated mobile user for PO Verification using Infologica SMS Adapter. The current workflow instance is placed hereafter into the waiting mode. The next step of the workflow is actually triggered by the mobile user (PO verifier) who sends SMS response to the Infologica SMS Listener. The workflow engine validates the SMS response from the verifier, wakeups the appropriate workflow instance and synchronises its context.
Being responsible for the conditional execution of the business process the workflow engine makes decision whether to proceed with the further approval or cancel the request. In case of successfull PO verification the next activity is invoked which sends SMS message to the nominated mobile user for PO Approval. The last step of the workflow instance is triggered by the SMS message from the PO approver. The workflow engine invokes the business activity which finalises the PO Status and optionally notifies client using Infologica SOAP Adaptor.
The workflow definition for the above PO Approval process was created using Infologica Workflow Designer. Workflow Designer is consistent with the Infologica Fusion component-centric architecture and provides business analysts with the high-level graphical abstraction to express the complex business logic and serialise it in a structured document format (XAML) as a workflow definiton. The initial workflow definition is then sent to the developer who is using the workflow designer to map the logical or event-bound containers to the actual implementation services (component activities) registered with the Infologica Fusion component container.
Infologica Workflow Designer utilises the Microsoft's System.Workflow.ComponentModel library to generate XAML document from the graphical abstraction but provides it's own implementation of the event-bound, logical and custom component activities (Infologica.Workflow.Activities) and Workflow Runtime Engine. The Designer helps to break the business process into the smaller reusable units of execution (activities) and invoke them asynchronously across and beyond the enterprise within the same application context.
All Enterprise Services from the Infologica Fusion Service Family can participate in the workflow process and contribute to the Infologica intelligent event-communication infrastructure. In the current demo the business process is initially triggered by the web service client. To define this event as a workflow instruction the business analysts simply drags the Listen Activity Container from the Activities Toolbox to the workflow designer canvas and selects SOAP Listener from the registered workflow trigger types.
The business analyst continues with the further process definition by setting all event-bound, logical and component activity containers according to the PO Approval logic. The final process instructions are sent to the programmer in the XAML format.
The workflow programmer assigns the fully qualified types of the Infologica Fusion component services to the workflow activities and provides the final mapping between selected trigger types and invocation end-points registered with the Infologica Fusion Framework. The programmer can also select the XSLT Template which will be used by the workflow engine to transform the inbound message before the component invocation.
Once the mapping is completed the workflow definition can be immediatelly registered with the Workflow Engine Database right from the Workflow Designer menu bar. Note that the Workflow Designer should be opened on the computer running the workflow engine to make the registration option available.
On the next step the Infologica Fusion Administrator is using the above XAML definition and Infologica Enterprise Management Console to configure the actual trigger end-points and make them workflow-bound.
Changing the service request processing type to the workflow-bound instructs the Infologica Trigger to do not process the inbound message but rather persist it in the Infologica Workflow Message Queue and attach the metadata identifying the trigger name and type. The workflow engine then parses the metadata and resolves the next logical activity and component service name it has to invoke on the next step.
Administrator also creates the new client subscription policy which represents the mapping between the client identity and the list of authorised web services. In this example Administrator creates the new web client "SAPClient" identified by the X.509 certificate with the subscription for the "SAP.POApprovalWorkflow" (PO Approval request entry point) and "Workflow" (generic web service providing status request).
Finally the Infologica Fusion Administrator configures all adaptors to the required infrastructure services using the Enterprise Management Console. The adaptor configuration includes the connectivity, probing, load balancing and failover information required by the Infologica Fusion Service Manager to provide an enterprise level of mediation between the business and infrastructure services layers.
Infologica Fusion Framework allows developer with a single Visual Studio.NET installed on his machine to transparently communicate with the remote infrastructure services via the Infologica Service Manager. There is no need for the developer to install any client software while debugging his distributed application logic. Infologica Service Manager abstracts developer from the data access or connectivity issues providing the intuitive command-based interface implemented by the Infologica Infrastructure Adaptors.
Developer is encouraged to create the reusable and environment-agnostic business code by providing the adapter's alias name and applying the same familiar syntax to invoke any infrastructure service. The code snippet below shows how easily developer sends SMS message for PO Approval using the "SMSProvider" alias configured by Administrator at the previous step.
Back to demos and tutorials