System and process for inter-domain interaction across an inter-domain connectivity plane

Description Submit all comments and votes

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to the field of supply chain, enterprise and site planning, and more particularly to a system and process for inter-domain interaction, processing and communication across an inter-domain connectivity plane.

BACKGROUND OF THE INVENTION

Supply chain, enterprise and site planning applications and environments are widely used by manufacturing entities for decision support and to help manage operations. Decision support environments for supply chain, enterprise, and site planning have evolved from single-domain, monolithic environments to multi-domain, monolithic environments. Conventional planning software applications are available in a wide range of products offered by various companies. These decision support tools allow entities to more efficiently manage complex manufacturing operations. However, supply chains are generally characterized by multiple, distributed and heterogenous planning environments. Thus, there are limits to the effectiveness of conventional environments when applied to the problem of supply chain planning due to monolithic application architectures. Further, these problems are exacerbated when there is no one "owner" of the entire supply chain.

It is desirable for the next evolutionary step for planning environments to establish a multi-domain, heterogenous architecture that supports products spanning multiple domains, as well as spanning multiple engines and products. The integration of the various planning environments into a seamless solution can enable inter-domain and inter-enterprise supply chain planning. Further, an important function provided by some planning applications is the optimization of the subject environment rather than simply tracking transactions. In particular, the RHYTHM family of products available from I2 TECHNOLOGIES provide optimization functionality. However, with respect to planning at the enterprise or supply chain level, many conventional applications, such as those available from SAP, use enterprise resource planning (ERP) engines and do not provide optimization. It is thus also desirable to expand planning analysis and optimization to the inter-enterprise or inter-domain level to enable planning optimization across the supply chain.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system and process for inter-domain interaction across an inter-domain connectivity plane are disclosed that provide advantages over conventional supply chain, enterprise and site planning environments.

According to one aspect of the present invention, a computer implemented system enables inter-domain interaction. The system includes a native plane that has a first native source associated with a first domain and a second native source associated with a second domain. The first and second native sources include domain related data and applications. The system also includes an inter-domain connectivity plane that has a first domain engine associated with the first domain and a second domain engine associated with the second domain. The first and second domain engines operate to perform domain analysis functions. The system further includes adapters associated with the first and second native sources where the adapters operate to abstract data and information from the first and second native sources onto the inter-domain connectivity plane. The first and second domain engines respectively receive data and information abstracted from the first and second native sources. The first and second domain engines also operate to perform global messaging between one another transparently supported by native messaging on the native plane.

According to another aspect of the present invention, a computer implemented process is provided for inter-domain interaction. A native plain is established that has a plurality of native sources respectively associated with domains where the plurality of native sources include domain related data and applications. An inter-domain connectivity plane is also established that has a plurality of domain engines respectively associated with the domains where the plurality of domain engines operating to perform domain analysis functions. Data and information is abstracted from the plurality of native sources onto the inter-domain connectivity plane and is received at the plurality of domain engines. Further, messaging is performed between the plurality of domain engines transparently supported by native messaging on the native plane.

A technical advantage of the present invention is that the inter-domain connectivity plane provides an abstracted layer to allow harmonization across distributed domains and provides significant advantages by harmonizing such aspects as object structure, messaging paradigm, naming and security.

Additional technical advantages should be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:

FIG. 1 is a block diagram providing an overview of one embodiment of a core environment that enables supply chain analysis and optimization according to the present invention;

FIGS. 2A and 2B are block diagrams illustrating conventional many-to-many conversion for inter-domain analysis and one-to-many conversion for inter-domain analysis according to the present invention;

FIG. 3 is a block diagram of one embodiment of relationships among adaptation dimensions associated with inter-domain analysis and optimization according to the present invention;

FIG. 4 is a block diagram of the visual information broker (VIB) operating as a middle tier to various engines and other data sources according to the present invention;

FIG. 5 is a block diagram showing the VIB interaction with various data sources as well as browser and non-browser user interfaces according to the present invention;

FIG. 6 is a block diagram of a business object server operating as data server according to the present invention;

FIG. 7 is a block diagram showing different components of queuing and the global messaging bus according to the present invention;

FIG. 8 is a block diagram showing transactional messaging between applications according to the present invention;

FIGS. 9A and 9B are block diagrams of a naive approach to inter-domain analysis and optimization and of the use of model agents as partial replicas according to the present invention;

FIGS. 10A and 10B are block diagrams of many-to-many interaction between domains and of simplified domain interaction enabled by the inter-domain connectivity plane according to the present invention;

FIG. 11 is a block diagram of one embodiment of an inter-domain connectivity plane according to the present invention; and

FIG. 12 is a block diagram of a hub and spoke collaboration network formed by engines on the inter-domain connectivity plane.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram providing an overview of one embodiment of a core environment, indicated generally at 10, that enables supply chain analysis and optimization according to the present invention. Core environment 10 provides a framework for inter-domain and inter-enterprise analysis and optimization. This framework allows optimization in the extended enterprise distributed environment. The framework also provides an inter-domain decision support environment that allows optimization for the extended enterprise. The framework further allows the embedding of other applications within it and can be embedded within other applications. Core environment 10 integrates multiple engines along multiple dimensions including user interface (UI), messaging, data access, data modeling and other dimensions. Core environment 10 provides scaleability, common protocols and security for supply chain planning and provides a universal adapter framework to provide connectivity between components and with other applications. All of the components and functionality within core environment 10, which are discussed herein, generally can be implemented by software executing on a computer device comprising typical components such as a processor, memory, input/output (I/O) devices and data storage devices.

As shown, core environment 10 includes a number of data sources 12 associated with planning environments that can be used by various enterprises and sites. Data sources 12 include, but are not limited to, legacy data sources (e.g., IBM mainframe and mid-range systems), relational database management systems (RDBMS) (e.g., ORACLE, SYBASE), enterprise resource planning systems (ERP) (e.g., SAP), I2 TECHNOLOGIES data sources, data warehouses and on-line analytical processing (OLAP) sources. Core environment 10 includes a supply chain data link 14 that provides a layer to interface to data sources 12. Supply chain data link 14 can, for example, be a layer established by the RHYTHM-LINK product available from I2 TECHNOLOGIES.

Business object servers (BOS's) 16 work through supply chain link 14 to interface with associated data sources 12. Alternatively, BOS's 16 can interface directly to data sources 12. For each data source 12, BOS's 16 use a dynamically loaded adapter to interface with the particular data source 12 and use a common BOS interface to communicate to higher levels within core environment 10. The structure and operation of BOS's 16 are also shown and described below. As shown in FIG. 1, BOS's 16 can interface to planning engines 18 which comprise various domain engines that handle planning analysis and optimization across the supply chain.

Planning engines 18 are integrated on an inter-domain connectivity plane 20. Inter-domain connectivity plane 20 provides an abstract layer for messaging and transfer of model agents that allow engines 18 to operate at the supply chain level. Inter-domain connectivity plane 20 is specifically geared towards inter-domain decision support, and the structure and operation of inter-domain connectivity plane 20 and its components are also described below. Among the functions provided by inter-domain connectivity plane 20 are messaging between domains, an advanced early warning system between domains for emergency events, the transfer of model agents and the enablement of loosely coupled optimization. Inter-domain connectivity plane 20 also allows interaction with custom applications 22 and support applications 24.

A visual information broker (VIB) 26 interfaces to inter-domain connectivity plane 20 to obtain information from various sources and package that information into a common format. The common format allows global user interface (UI) 28 to use a library of interface components that does not need to be changed every time the information source changes. In one embodiment, user interface components are implemented using JAVABEANS or ACTIVEX user interface components, and the JAVA language is used to provide extensibility. Analogous to BOS's 16, visual information broker 26 uses dynamically loaded adapters specifically designed to interface to particular sources of information. Core environment 10 also includes a global message bus and abstract queuing 30 which enables interaction between engines 18 on inter-domain connectivity plane 20. In one implementation, synchronous communications are handled by common object request broker architecture (CORBA) and distributed component object model (DCOM), and asynchronous communications are handled by supporting many messaging layers, including, but not limited to, TIBCO, MQSERIES, ACTIVEWEB and SMTP (simple mail transfer protocol).

Within core environment 10, global user interface 28 supports a common user interface across multiple engines 18 and sources 12. Global user interface 28 allows a common set of reusable, data-aware components to be established across the multiple engine types. A number of data-aware user interface components can be supported such as: tree, tree-table, table, two-dimensional and three-dimensional charts (line, bar, Gantt, pie), maps and graphs, multi-dimensional, and axis-cross. Global user interface 28 also can establish a common extensibility mechanism, a common security framework and a common user model.

Core environment 10 can support a number of distinct kinds of user interfaces, including, for example, an ACTIVEX user interface, a JAVABEANS-based stand alone user interface, a JAVABEANS-based browser user interface and a dynamic-SHTML servelet user interface. The ACTIVEX user interface can be supported via a COM interface to a data manager, which can be a sub-component of visual information broker (VIB) 26. Also, data aware ACTIVEX components that are aware of VIB 26 data models can be provided. This user interface would also support JAVABEANS components wrappered as ACTIVEX. The JAVABEANS-based stand alone user interface can include JAVABEANS that are aware of VIB 26 data models. This user interface would support ACTIVEX components wrappered as JAVA components using the MICROSOFT JAVA virtual machine. The JAVABEANS-based browser user interface can be a pure JAVA user interface. It can be designed to run in any browser as well as on network computers. As a pure JAVA interface, the user interface will run inside any JAVA virtual machine (JVM). The dynamic-SHTML servelet user interface can be designed for low-bandwidth situations such as those found on the Internet. This approach distributes the processing at the server side producing dynamic HTML pages that are displayed on a web browser.

In general, core environment 10 is designed to integrate existing and future planning engines at multiple levels and possesses a number of key attributes. Core environment 10 is designed to be open and establish protocols by which applications can be developed to operate under core environment 10. Core environment 10 is component based and uses standard component architectures. For example, CORBA and DCOM can be used as a distributed component architecture, and JAVABEANS and ACTIVEX can be used as user interface component architecture. By having a component architecture, core environment 10 allows changes to be released in pieces and not all at once, allows users to select and use only components that are useful, allows components to be re-used, and allows third party components to be incorporated.

Core environment 10 can be scaleable in a variety of different ways. Components can be load balanced and multi-threaded which leads to higher throughput. As described below, the universal adaptor framework avoids the many-to-many issue which leads to greater scaleability. Further, security is handled by core environment 10 so that individual engines do not have to be worried about security. This also leads to greater scaleability.

With respect to security, core environment 10 can provide a number of forms of security. For example, there can be security between user interface 28 and visual information broker 26 and messaging security. In both cases, both encryption as well as user authentication can be provided. An important aspect is that core environment 10 can implement security in such a way that it does not require each and every engine to be concerned with security.

Core environment 10 may, however, place some minimal requirements on the engine architecture. In one implementation, core environment 10 makes the assumption that an interface can be provided to the engine that is either an external interface or an in-memory JAVA interface. In this implementation, if an external interface is provided, the interface can be a CORBA interface, a COM/DCOM interface, a shared library, structured query language (SQL), an object database interface or a socket interface. If an in-memory JAVA interface is provided, the interface can typically be accomplished by embedding a JAVA virtual machine (JVM) in the engine and writing a local JAVA interface (LJI) that calls the local native interface (LNI) via the JAVA native interface (JNI). Another assumption that can be made about the engines is that the engines have an ability to be a CORBA client and have the ability to marshall CORBA structures. Native components can be provided for both of these tasks. However, in this case, core environment 10 specifically does not make the requirement that an engine must be a CORBA server (which would require hooking up the engine's event loop with the CORBA event loop).

Universal Adapter Framework

One problem in creating core environment 10 is matching an interface (along some dimension) of one product or application with that of another. One possible solution is to write converters between all possible combinations of interfaces. However this leads to a classic many-to-many problem where the number of converters is unmanageable. FIG. 2A is a block diagram illustrating this conventional many-to-many conversion problem for inter-domain analysis. As shown, an environment 40 may contain a plurality of products, applications, data sources or other entities 42 that need to interface with one another. In environment 40, there is a converter, represented by the lines, associated with the interface between each pair of entities 42. As can be seen, this many-to-many solution will generate a requirement to create and manage a prohibitively large number of converters as the number of entities 42 increase.

FIG. 2B is a block diagram illustrating one-to-many conversion for inter-domain analysis according to the present invention. This solution is enabled by a universal adaptor framework in which the different adaptation dimensions use the same mechanism for adaptation. As shown, an environment 44 can contain a plurality of products, applications, data sources or other entities 46. However, unlike environment 40 of FIG. 2A, environment 44 further includes a universal interface 50. With this scheme, only one adapter 48 needs to be created and managed between each entity 46 and universal interface 50. In general, an adaptor 48 maps a proprietary interface from an entity 46 into universal interface 50. This allows a one-to-many conversion instead of the many-to-many conversion of FIG. 2A. Further, adapters 48 can be dynamically loadable such that an appropriate adapter 48 can be loaded when an interface to a particular entity 46 is needed and then removed if no longer needed.

This universal adaptor framework works across multiple dimensions using dynamically loaded adaptors 48. These adaptation dimensions can include visual (handled by VIB), data (handled by BOS's), messaging and queuing. Dynamically loaded adapters 48 help to establish openness within core environment 10 and can use the same mechanism across all adaptation dimensions. This reduces the learning curve for users and developers within core environment 10.

Adaptation Dimensions

FIG. 3 is a block diagram of one embodiment of relationships among adaptation dimensions associated with inter-domain analysis and optimization according to the present invention. FIG. 3 shows an example environment, indicated generally at 60, that includes four adaptation dimensions--user interface, data, queuing and message bus--all of which involve dynamically loaded adapters.

Beginning with data sources, environment 60 includes a planning engine 62 and data storage 64 accessed by a business object server (BOS) 66 using dynamically loadable adapters 68 and 70. An SAP based system 72 and an ORACLE based system 74 are linked through a RHYTHM-LINK application 76. A second BOS 78 then accesses both data storage 64 and RHYTHM-LINK application 76 using adapters 80 and 82. Similarly, a common data model storage 84 is accessed by a BOS 86 and a BOS 90 using adapters 88. BOS's 66, 78, 86 and 90 all interface to a domain engine 92, which can be one of a number of domain engines operating within a supply chain. In addition, RHYTHM-LINK application 76 can be enabled to interface directly to domain engine 92, and in particular can do so when domain engine 92 is an I2 TECHNOLOGIES' product. Domain engine 92, in turn, provides information to a visual information broker 94 through dynamically loadable adapters 96. Visual information broker then provides data to a common user interface (UI) 98 for providing a display to a user. Environment 60 also includes a global message bus 100 which uses adapters 102 to interface to native messaging functionality and allow engine 92 to interact with other domain engines. Global message bus 100 also interfaces with a queue adapter 104 that uses adapters 106 to allow messages to be persisted on either a relational database management system (RDBMS) 108 or an object oriented database management system (ODBMS) 108. This persistence can form the basis for guaranteed message delivery.

The user interface adaptation dimension concerns the presentation of information to users and involves common user interface 98, visual information broker 94 and adapters 96. For example, if an engine 92 needs to be accessible from common user interface 98, then the engine 92 should have visual information broker (VIB) adaptors 96 created for it. Likewise, although not shown, if an application needs to embed an engine 92 into the application's user interface, then the application's user interface can make a call to visual information broker 94 which, in turn, interfaces to engine 92.

The data adaptation dimension concerns the accessibility of data to an engine 29 and involves BOS's 66, 78, 86 and 90 and BOS adapters 68, 70, 80, 82 and 88. If an application or data source needs to be accessible from engine 92, then there should be business object server (BOS) adaptor created for the application or data source.

The queue adaptation dimension concerns queues for transactions and is not directly illustrated in FIG. 3. Queue adaptors, for example, allow queues to be built on transactional databases, including relational database management systems (RDBMS's), such as ORACLE and SYBASE, and object data base management systems (ODBMS's). Queue adapters can be built to any transactional database a main application or engine is using. The queue adaptation layer is also shown and described below.

The message bus adaptation layer concerns communication over message layers and involves global message bus 100 and adapters 102. For example, if an application needs to have communication to an engine 92 implemented over the application's native message layer, then an adaptor 102 can be created to that native message layer.

Visual Information Broker

FIG. 4 is a block diagram of the visual information broker (VIE) operating as a middle tier to various engines and other data sources according to the present invention. As shown, a first engine 110 (of type 2) has an engine interface 112, and a second engine 114 (of type 1) has an engine interface 116. The visual information broker (VIE) 118 accesses engine interface 112 using an adapter 120 and accesses engine interface 116 using an adapter 122. Visual information broker 118 can then provide information to a user interface 124 which can include a local caching proxy server 126.

VIB 118 then has a common interface which can be accessed by user interface 124 regardless of the type of engine from which VIB 118 obtains information. As mentioned above, user interface 124 can thus include a library of data-aware components such as ACTIVEX and JAVABEANS components. VIB 118 can route incoming requests from user interface 124 to engines 110 and 114 which are of different types. VIB 118 can also load-balance engines of the same type. Such a data manager sub-component of VIB 118 is a part of the universal adaptor framework described above. VIB 118 and adapters 120 and 122 allow user interface-oriented data models from multiple engines 110 and 114 to be adapted into a common data model oriented for user interface 124. This forms a basis for common user interface 124.

VIB 118 can provide an interface across multiple sources including databases, in-memory engines, CORBA servers, flat-files, messaging, object databases, etc. VIB 118 uses dynamically loadable adapters as appropriate to interface with the sources. The adapters can be specifically designed to connect to desired source and to VIB 118. This scheme allows support of a wide variety of data models, including tables, trees, name-value pairs, multi-dimensional, and object graphs.

FIG. 5 is a block diagram showing interaction between the visual information broker and various data sources as well as browser and non-browser user interfaces according to the present invention. As shown, the environment can include a browser user interface 130 and a non-browser user interface 132. Browser user interface 130 connects through a workstation 134 that provides a firewall 136 and an IIOP tunnel 138.

A visual information broker (VIB) 140 can provide access to information sources 142 (DCOM, CORBA) for both IIOP tunnel 138 and non-browser user interface 132. VIE 140 can also interface with a VIE 144. Another VIE 146 can provide access to information sources 148 (SQL, OLAP, I2-FP, I2-SCP) for non-browser user interface 132. As with VIE 140, VIE 146 can also interface with VIE 144. VIB's 140, 144 and 146 can be designed to access multiple data sources simultaneously, and the data sources can include: CORBA servers, DCOM servers, COM objects, RDBMS data, ODBMS objects and in-memory objects. Further, VIB's 140, 144 and 146 can be load-balanced to divide the load across multiple servers or other sources of information, and this load-balancing can be transparent to user interface 130 or 132.

Visual information brokers can support a multi-threaded environment with a thread-pool model where individual requests can be executed in their own thread until a certain maximum number after which they can be queued. Visual information brokers also can be directly embedded in an engine and can run on the same machine as the engine for high-throughput compared to network access.

In one embodiment, visual information brokers include data manager, event channel and page manager sub-components. The data manager sub-component can be accessible via CORBA as well as COM and supports multiple data models including: tree-table, name-value list, axis-cross, multi-dimensional and object graph. The data manager can also support client-originated execution of model agents. The event channel sub-component allows the common user interface to subscribe to and be notified of server events. The page manager sub-component can allow a user interface to be created in an SHTML format. This format allows inter-leaving of static HTML with dynamic servelets. It is more efficient than CGI since it does not require a separate process spawned per request, but only a separate thread per request (up to a maximum since it uses a thread-pool model). The page manager also can be compatible with the JAVASOFT servelet application program interface (API). It can load in standard servelet components as well as application-specific servelets. The page manager can be similar to a JAVASOFT JAVASERVER with a number of additional features and differences. The page manager can be instantiated stand-alone or within another process. In process instantiation allows a very tight coupling between the servelet and the process. The page manager can be load-balanced and is designed to work with a web server and not be a replacement for one. The page manager also links servelet parameterization with page parameterization so that dynamic servelets can form direct parameterized links to SHTML pages.

Business Object Servers

FIG. 6 is a block diagram of a business object server (BOS) operating as a data server according to the present invention. A number of data sources 150 have associated dynamically loadable BOS adapter's 152 that interface between data sources 150 and a business object server (BOS) 154. Business object server 154 includes a BOS interface 156 which can be standard across business object servers. A BOS client 158 can then interface with business object server 154 through BOS interface 156. As shown, BOS client 158 can read from and write to data sources 150 through business object server 154, and business object server 154 can handle the specific interface with data source 150 via an appropriate BOS adapter 152. The dynamically loadable nature of BOS adapters 152 mean that they can be loaded as needed and then removed without having to otherwise affect the operation of business object server 154.

In general, BOS client 158 can be a planning engine, and business object server 154 can serve up objects to the engine from multiple different data sources 150. In this manner, business object servers 154 form an integral part of the described universal adaptor framework. BOS adapters 152 adapt data from the multiple data sources 150 into specific business objects. Each business object server can thus be classified by the data source interfaces to which it adapts.

BOS adapters 152 to data sources 150 can have a common model and an other model format. For the common model format, a standard BOS interface 156 and standard BOS adaptors 152 can be fused into a single object. Effectively, in this case, BOS adaptors 152 then provide only an object-relational mapping. For non-standard BOS adapters 152, an application can be provided to allow development of special business object servers 154 as well as BOS adaptors 152. For the other model format, there can be BOS adaptors 152 to many non-standard data sources 150, including enterprise resource planning (ERP) systems and other planning systems. BOS adaptors 152 can operate to make accessible proprietary non-standard data sources 150. For the other model format, an application can, again, be provided to allow development of special business object servers 154 and BOS adaptors 152.

Queuing and Messaging

FIG. 7 is a block diagram showing different components of queuing and the global messaging bus according to the present invention. The queuing and global messaging are also built upon the described universal adaptor framework. With respect to queuing, a storage 160 can contain queues 162 that include transactions for a relational or object database management system (RDBMS, ODBMS). A dynamically loadable queue adapter 164 provides an interface from a queue manager 166 to queues 162. Queue manager 166 includes a queue application program interface (API) 168 that can be standard across queue managers 166. A transactional message manager (TMM) 170 and an application 172 can interface to queue manager 166 via queue API 168.

Similarly, with respect to global messaging, transactional message manager (TMM) 170 and application 172 can interface through a message bus API 174 to a message bus manager 176. Message bus manager 176, in turn, can use a dynamically loadable message bus adapter 178 to interface to native messaging 180 of the underlaying native applications. This allows global messaging to be built on top of any third party messaging solutions including, for example, ACTIVEWEB, TIBCO, MQSERIES, NEONET, SMTP and FTP. This also allows applications 172 to be abstracted from the underlying native message layer 180. In one embodiment, three levels of messaging are provided having different characteristics: fast/reliable messaging; certified messaging; and guaranteed/transactional messaging. The fast/reliable messaging can provide a reasonable efforts attempt to deliver the messages. The certified messaging can provide certifications of message delivery to the client application. Third, guaranteed/transactional messaging can be provided between queues on transactional databases to ensure delivery of messages, including messaging between different transactional databases (e.g., between ORACLE and SYBASE databases or between RDBMS and ODBMS databases).

FIG. 8 is a block diagram showing transactional queuing and messaging between applications according to the present invention. As shown, a first application 190 has a transactional context that can include a storage 192 holding relational database information 194 and transactional queues 196. A queue manager 198 provides an interface to queues 198 for application 190 as well as a transactional message manager (TMM) 200. Within a messaging transactional context, a message bus manager 202 provides an interface between transactional message manager 200 and native messaging layer 204.

Similarly a second application 206 has a transactional context that can include a storage 208 holding object database information 210 and transactional queues 212. A queue manager 214 provides an interface to queues 212 for application 206 as well as a transactional message manager (TMM) 216. Within the messaging transactional context, a message bus manager 218 provides an interface between transactional message manager 216 and native messaging layer 204.

This framework allows an abstract queuing and global messaging layer between applications 190 and 206 to be supported on an underlying native messaging layer 204. Within this messaging framework, point-to-point messaging with global addressing, publish and subscribe messaging and efficient encrypted, user-authenticated messaging can be supported. Further, an out-of-the-box solution consisting of message bus adaptors to ACTIVEWEB or TIBCO, and queue adaptors on top of an ODBC compliant database can be provided. These adaptors can be bundled along with the messaging solution (ACTIVEWEB or TIBCO) to crea