Evolution of uploading, downloading, and deleting attachments in BPM and portal Projects

The entire project is divided into BPM and portal sections, during which attachments are uploaded, downloaded, and deleted. In the BPM part, attachments always exist as process attachments. Therefore, the content of this attachment is stored in a table of the database regardless of the number of processes, there is only one more sign of the process ID, and the information next to it can be set in the respective process vwattachment (see: http://blog.csdn.net/dongzi87/article/details/7163679).As a result, the attachment business operations are much less, so that a process attachment upload component can be easily formed. The architecture is as follows:

Only the processes that show the operations of some accessories of the process are independent of the business of the process itself. The operations of attachments and related information in the portal are not independent. There is a need to define this, because the workflow and portal have different attachment requirements, and their embodiment in the architecture is naturally different.

In the portal Information Service Processing, attachments are uploaded and deleted, while each function module in the portal background management has different requirements on services. Therefore, the attachment upload/deletion service forms a specific component, as shown below:

In BPM, the attachment upload, download, and deletion services have one component. In the portal, the attachment upload and deletion are accompanied by other services, in BPM, users process this point in time. So it adopts the form, and the download process does not contain other business components, so it evolves back to the operations similar to some of the attachments in the process. As follows:

Combined with these images and the business and attachment operations in BPM and portal, it is easy to find that what it wants is not the determination of the entry address (starting from the corresponding action of the business, or from the action of the attachment component), but to the business encapsulation: The attachment operation does not carry other services; the attachment operation carries Other business operations before and after. Abstract to this point, you can apply some content in the mode to briefly present this idea: You can have attachment operations for business operations or attachment operations for business operations, depends on the implementation class (specific business.

As shown in the preceding figure, file operations and service operations may be replaced as needed. In short, the operations of attachments in BPM and portal can be ultimately attributed to a component. This needs to be incorporated into the architecture, or even as the core service layer of the architecture, depending on the proportion of the business of this block. Shows the evolutionary diagram: