Using business processes and contexts
This section follows a message from it's inception through the first two steps of the business process of Figure 6-2. The message is first created, then it is send and consecutively received by the receiver. He then processes the message and sends a reply.
The message that is send
To send a message, first the envelope, message and business process model have to be integrated into one DTD. With this DTD it should be possible to send a message containing the following functionality:
Addressing (from/to)
Name of business process and the step therein
List of built objects in view format
The contextmanager.py script takes as it's input the desired language, the business process and the field (like "prefab concrete elements"). It's output is a DTD, suitable for sending messages in the selected language, with the business process and in the selected field. In the section called pce_en_procurement.dtd in Appendix F you find a sample DTD, generated for communicating in the English language about prefab concrete elements. This DTD was used to fill a message, which is included below (Example 7-1). This message is a request from a contractor to a central repository (www.cexml.org, a fake address) which has knowledge of the two catalogs owned by the English and the Dutch supplier.
Example 7-1. request1.xml
<!DOCTYPE envelope SYSTEM "pce_en_procurement.dtd">
<envelope>
<sender>
<!-- The addresses are in a format useful for a
quickly hacked prototype :-) -->
<address>../contractor/</address>
</sender>
<recipient>
<address>../cexml/</address>
</recipient>
<businessprocess>
<bpname>procurement</bpname>
<bpstep>parts_needed</bpstep>
</businessprocess>
<message>
<cexml>
<hollow-core-slab amount="5">
<span m="5"/>
</hollow-core-slab>
<reinforced-rectangular-beam amount="4">
<span m="5"/>
</reinforced-rectangular-beam>
<double-T amount="8">
<span m="5"/>
</double-T>
</cexml>
</message>
</envelope>
|
Sending and receiving the message
The message is send by feeding above request (Example 7-1) to the small sender.py script (Example 7-2).
Example 7-2. sender.py
#!/usr/bin/python
import cexmlhelper
import os
import sys
cexmlhelper.set_linux_classpath()
temp=cexmlhelper.process_with_xslt("%s"%sys.argv[1],"../cexml/dispatcher.xslt")
os.system("exec `cat %s` %s"% (temp, "%s"%sys.argv[1]))
|
This script runs the request trough a stylesheet that extracts a command-line out of it. It takes for instance the name of the business process, prepends the address of the recipient (which was specified in the form of a Unix pathname, every actor has it's own directory), thereby forming the name of an executable command. The location of the request is passed along as a command-line parameter so that the executed program can read it.
Processing the message
The called program has the name of the business process (in this case procurement). In much the same way as the process described in the section called Visualising the catalogs, the actual message is stripped from it's containing envelope and (in reaction to the specific business process step), it is joined with both the English and the Dutch catalog. The information again is "propagate"d and "rejoin"ed. A new process is the search.xslt XSL/T stylesheet, which can be found in the section called search.xslt in Appendix E. This stylesheet looks for all builtobjects with a mode="search" attribute. It then searches for a builtobject exact matching the searched-for name and the - in this case - correct desired quantification span. Then all not-searched-for builtobjects are stripped out and the reply basically is ready.
Sending a reply
The reply can be send in much the same way, but it is more illustrative if I format the answer for printing. This is done by converting it (by using print_answer.xslt, the section called print_answer.xslt in Appendix E) to a file with XSL/FO instructions. This is then processed with xml.apache's FOP (xsl/FO Processor) and the resulting PDF file is printed. This is done by the small script print.py (the section called print.py in Appendix D). The result can be seen in Figure 7-6.
Conclusions
It is possible to have a context-manager assemble a purpose-built DTD which can be used to write a message that can be send from one party to another. For this, only the data contained within the message is needed, no extra information needs to be specified e.g. on the command-line. Searching for a specific item in both catalogs is possible, whatever the language of the catalog. Also it is possible to generate nicely formatted output on the fly.