Abstract:
A simple message mechanism serves to interface applications within content management system. The message management mechanism operates by extracting at least one selected parameter during execution of at least one task (e.g., application) during content workflow. The operator is then notified of whether the at least one task executed successfully in accordance with the extracted parameter.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 60/923,028, filed 12 Apr. 2008, the teachings of which are incorporated herein. 
     
    
     TECHNICAL FIELD 
       [0002]    This invention relates to a technique for interfacing elements in a content management system. 
       BACKGROUND ART 
       [0003]    Entities, such as broadcasters, that receive, process and/or distribute content, in the form of electronic files containing audio-visual programs, typically make use of large systems for managing such content. For ease of discussion, the receipt, processing and/or distribution of content collectively comprise the general task of content workflow. 
         [0004]    The processing of content within a particular content work flow can include various operations. A given operation, such as non-linear editing for example, will typically require at least one, and sometimes several different elements, each comprising either hardware, software, or a combination of both. In many instances, a single vendor might offer all of the elements necessary to carry out a given content processing operation or set of operations. However, other content processing operation can require elements from several different vendors. 
         [0005]    The combination of elements from several different vendors to carry out one or more processing operations can pose problems in terms of content standardization. For example, within the media industry, hundred of solutions exist to manipulate the content by way of non linear editing. For this reason, some vendors offer equipment compatible with several known standardized formats, such as the Advanced Authoring Format (AAF) which makes use of an edit decision list with reference to the edited material. The AAF format has not enjoyed universal acceptance and typically finds application in specific areas like post production. The Material EXchange Format (MXF) has become a standard for streaming and storage of content and handles the transport of essence and metadata well, including multilayers and segment content. However, MXF only works well with for simple composite content and lacks universal applicability. For this reason, a number of suppliers of content process equipment support the AAF standard. However, present day solutions do not address operational aspects like task description, usage of the content, and priority. 
       BRIEF SUMMARY OF THE PRESENT INVENTION 
       [0006]    Briefly, in accordance with a preferred embodiment of the present principles, there is provided a method to manage applications with limited interfacing capability with a framework that manages workflow in order to optimize operation. The method provides a simple message mechanism to interface applications within an operational workflow management solution. The method of the present principles commences by extracting at least one selected parameter during execution of at least one task (e.g., application) in a content workflow. The operator is then notified of whether the at least one task executed successfully in accordance with the extracted parameter. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  depicts a block schematic diagram of a content management system that makes use of the message management technique of the present principles to interface with 3d-party subsystem; and 
           [0008]      FIG. 2  depicts in flow chart form the steps of a process in accordance with the present principles for managing messages to interface the 3d-party sub-system to the content management system of  FIG. 1 ; 
       
    
    
     DETAILED DESCRIPTION 
       [0009]      FIG. 1  depicts a content management system  10 , such as the Thomson Grass Valley “Content Share CS2” system available from Thomson Grass Valley, Beaverton, Oreg. The content management system  10  comprises a processor (not shown) in the form of a personal computer or mini computer that interfaces with one or more elements comprised of hardware, software or a combination of both. A primary element within the content management system  10  is a work flow element  12  which dictates various content manipulations performed by the content management system. Depending on the desired content workflow, the workflow engine  12  could ask to perform a content manipulation function such as non-linear editing. Another content manipulation operation could include content compression. Other content manipulation operations are well known and will not be described here. 
         [0010]    Another element within the content management system  10  is a User Interface (UI) Application  14  that enables one or more operators to interact with the content management system via devices such as a keyboard and touch screen. In addition, the UI Application  14  extracts data from the content management system and manipulates that data for display on one or more monitors (not shown) to provide the operator with information indicative of the operation of the content management system. 
         [0011]    Another element within the content management system  10  is a Product Life Cycle Management (PLM) module that operates to track the operation of the content management system. The PLM interfaces with super systems, such as a Traffic System which controls resources and provides a process device resource management layer, which allows timed operations, such as Quality of service, 
         [0000]    in the entire system. 
         [0012]    The content management system  10  includes an infrastructure having various parts which include a web service module  18  comprising software and/or hardware to link the content management system  10  to a network, such as the Internet. The content management system infrastructure also comprises a Software Development Tool Kit (SDK)  20  that includes one or more software programs accessible by an operator that allows for the addition, deletion and/or modification of software within the content management system  10 . Lastly, the content management system infrastructure includes a core services module  22  that controls a core service such as the receipt of incoming content, the distribution of finished content, the collection of recording keeping information, and similar such functions. 
         [0013]    The content management system  10  includes at least one, and preferably a plurality brokers  24   1 ,  24   2 . . .  24   n , where n is an integer, each broker serving to interface the content management system to a separate one of devices  26   1 - 26   n , respectively. Each of the devices  26   1 - 26   n  performs at least one function, and often, a plurality of functions, in connection with the receipt, processing, storage and/or distribution of content. Brokers serve as the interfaces to external process devices. In actuality, the brokers actually abstract the functionality of the various process devices and provide generalized interfaces for the content management system internal clients, which use the functionality of the process devices to provide a complex overall workflow. The process devices can be of course from the same manufacturer most often these process device will be from a third party, which will be integrated into the content management system using a corresponding Broker as interfaces. 
         [0014]    In addition to the devices  26   1 - 26   n , the content management system  10  includes an intelligent workflow gateway  28  which serves as a interface to link the content management system  10  to one or more independent third party sub-systems, illustratively illustrated by sub-system  30 . The sub-system  30  typically includes a processor or the like (not shown) which controls at least one content manipulation application  32 , either in the form of hardware, software or a combination of both. The content manipulation application  32  can itself perform one or more content manipulation operations, or it can do so with the aid of one or more device  34 , similar in nature to the devices  26   1 - 26   n . 
         [0015]    The intelligent workflow gateway  28  is mainly used to decouple the content management system work flow engine  12  from the independent sub-system  30 . In any case, the initial stimulus for the operations comes from the workflow engine  12  which forwards a workorder to the sub-system  30  via the intelligent workflow gateway  28 . The Workorder includes information regarding a threshold (e.g., a parameter value) in the sub-system  30  which must be achieved and then trigger the backward messaging event to inform the workflow engine  12  about the successful completion of the Workorder sent to the sub-system  30  In addition the intelligent workflow gateway  28  can receive further information expected back from the sub-system  34  together with Workorder completion notification. 
         [0016]    The intelligent workflow gateway  28  then independently monitors the execution of the Workorder (Tasks) at the sub-system  30  and delivers the expected information based on the previously established workorder completion threshold. Once the intelligent workflow gateway  28  has triggered the waiting work flow engine  12  workflow, the information thread is back in the workflow engine, which continues according to the workflow as part of the running Workpackage. 
         [0017]    In accordance with an aspect of the present principles, the third party sub-system includes a messaging module  36  that takes order messages from the workflow mgmt system and provides response messages to the workflow engine of the content management system  10  indicative of a particular activity to alert an operator of the successful occurrence of a particular activity. The messaging module  36  typically takes the form of software that executes a process depicted in flow chart form in  FIG. 2 . The messaging process depicted in  FIG. 2  commences upon execution of step  200  at which time an operator will typically establish the desired information for monitoring. In practice, the operator will typically want to know whether a given application within the content workflow performed by the sub-system  30  of  FIG. 1  has executed properly. In addition, the operator might wish additional information, such as logging and timing data for example. Rather then the operator establishing the desired monitoring information during step  200 , the messaging module  36  of FIG. could establish a default set of monitoring information which an operator could modify as desired. 
         [0018]    Following step  200 , step  202  of  FIG. 2  undergoes execution, whereupon the messaging module  36  of  FIG. 1  determines associated parameters for the desired monitoring information. Typically, the monitoring information gathered in connection with a particular activity will have one or more parameters associated therewith. Thus, the associated parameter(s) will themselves yield information about the activity, such as whether the activity executed successfully, 
         [0019]    Next, steps  204  of  FIG. 2  undergoes execution and the messaging module  36  of  FIG. 1  extracts the associated parameters previously determined during step  202  for the current activity undergoing execution by the content manipulation application  32  of  FIG. 2 . The messaging module  206  of  FIG. 1  then examines the extracted parameters during step  206  to evaluate application execution. As discussed previously, one or more of the associated parameters determined during step  202  can provide an indication of whether the application executed successfully. Thus, by examining the parameters during step  206 , the messaging module  36  can make a decision during step  208  whether application execution was successful. Depending on whether the application execution was successful, the messaging module can report successful application execution, or failure, during steps  210  and  212 , respectively. In addition to reporting the status of the application execution during steps  210  and  212  of  FIG. 2 , the messaging module  36  of FIG. I can also report other information, such as logging and or timing data, during each of these steps. Following execution of either of steps  210  and  212 , process execution returns to step  204  until such time extraction of the parameters of a given application has occurred, and no further applications await execution. 
         [0020]    The foregoing describes a technique to a technique for interfacing at least one sub-systems element in a content management system by providing messages indicative of the sub-system operation.