SE515343C2 - Support function for mains elements - Google Patents

Abstract

The invention relates to a method for transforming data to a desired format in a network element. The network element is included in a data network with an operations support system (104) for operation and maintenance of the network, and comprises a resource layer (106) including resources (108) in the form of hardware and software. The resources include network element functions providing services in the network, as well as resources used for realizing the network element functions. Furthermore the network element includes an operations support view (110) consisting of software and in which the network element (102) from the operations support system (104) looks like consisting of a number of resource representations (114) and is used by the operations support system for managing a respective resource and network element function in connection with performing a network element function. The method implies that on demand an operation is started including that data in the resource layer are fetched by a communication function (122). The communication function sends these data to be transformed to the desired format by a transformation function (124). The transformation function carries through the transformation and returns the transformed data to the communication function for forwarding to a desired instance.

Description

51.5 343 2 is commonly used for storage from what is required by an external user. It is also possible that the actual information transfer will be performed using an FTAM file management system according to ISO 8571, the user assuming the role of "initiator" according to the definition this concept has obtained in FTAM.

For reasons of efficiency, it would be desirable for data retrieval, formatting and transfer to take place in as few steps as possible. This in turn requires effective collaboration between several independent sets of software. In the case of log mail management, e.g. log mail retrieval of general software in a basic system, as well as the transmission. The formatting, on the other hand, is handled by software, which belongs to the application that entered the log entries in the log in the first place.

For such a working scenario, it is necessary that the network element can present the transmission parts as "virtual files" in a "virtual file store" against FTAM.

State of the art.

US 5,299,304 discloses a method and apparatus for identifying multi-stage format transformations of documents.

US 5,317,676 describes the interactive definition of filters to perform data transformations in series and thereby perform more complex mathematical operations on data.

US 5,339,392 discloses a method of creating a user-definable, video-presented document which shows changes in real-time data. The user can choose which real-time data is to be displayed, as well as where and in what format and appearance it is to take place.

US 4,559,614 discloses transforming data transmitted from a remote information management system operating with a first internal code format to the internal code format of a second receiving information management system.

EP 0 631 246 describes the control of object presentations in a user interface of a data processing system. When an object is selected for presentation, the object is transformed into a presentable format according to its attributes. ,. . . . EP 5,537,834 discloses a data reception architecture that allows free definition and redefinition of the format of document forms without requiring reprogramming of data processors that receive and use data on the forms in question.

EP 0,408,132 describes a system for managing data files. The system has a modular structure with a control module and a plurality of converters, each of which is intended for a particular type of conversion.

EP 0,350,654 describes a data processing system in which an input record is transformed into a record of a uniform format. All file formats are made uniform. A desired entry is read from a file and transformed into an arbitrary format.

EP 0 377 783 describes the use in a transitional stage of a language representation which is to facilitate the optimization of transformations in a computer program which is being compiled. 1 ..

An object of the invention is to provide a support function for use in a network element of an initially defined type, which enables easy transformation and transfer of information present in the resource layer to a format desired by an external user.

A further object is to provide a method for transmitting data to a desired format in a network element of the type initially indicated.

The above objects have been achieved by those in claims 1, resp. 7, wherein embodiments have obtained the features specified in the respective subclaims.

According to an aspect of the invention, the resource layer of the network element includes a support function, which comprises a first software function, which is intended for retrieving and providing data appearing in the resource layer for post-handling, and a second software function, which communicates with the first software function and is intended for receiving data provided by the first software function, and afterwards. «. .w ».l. .. i, n. ..,. ; v 1 u, æ -. ß - .H1 - | 1 .m .U -. f »n - Q n. . f n | -. n f »I v _. u. w .. 4 handling these to a state, required by an external user in the network.

The support function according to the invention constitutes for a user a tool which enables retrieval and transformation / formatting of data in records to external formats. Data can then be output via file transfer or other external communication, such as tapes, printers, etc., which are available in a current system.

The transformation itself is carried out by means of a transformation function utilized by the support function.

The transformation function can be selected during driving time and the available set of transformation functions can be extended during driving time.

Such a transformation function consists of at least one transformation component, which in turn can use one or more, replaceable, transformation functions. It is thus possible, in driving time, not only to select but also to compose new transformation functions.

Each transformation component has a characteristic interface that determines the type of both input and output. A connection point for a transformation function also has a characteristic interface. A transform function can be connected to a connection point if and only if the two interfaces are equal.

Connection points for transformation functions can be found in any software component, e.g. in a transformation component.

A transformation function is a transformation component that has transformation functions connected to all its connection points (eg a transformation component that has no connection points). Its characteristic interface is by definition equal to the transformation component.

Each application / market may implement appropriate such transformation components, and reuse and modify transformation components during runtime. You can create any format, including standard formats, which means that adaptation to existing standards is possible.

B15 545 5 Description of the drawings.

The invention will now be described in more detail below with reference to the accompanying drawings, in which Fig. 1 illustrates in a schematic view the connection between operating support, data and resources at a network element according to the invention, Fig. 2 in a similar view as in Fig. 1 schematically Fig. 3 illustrates the structure of a transform function which transforms data into a format required by an external user, Fig. 3 in a similar view as in the preceding figures schematically illustrates the structure of a parent support function, in which the transform function is included, Fig. 4 is a view which illustrates in more detail a possible construction of the transformation function, Fig. 5 is a view which schematically illustrates retrieval / collection of information from a log for post-handling, Fig. 6 is intended to further illustrate certain contexts when handling in two handling views, which described with reference to Figs. 1-3, Fig. 7 illustrates an example of a scenario according to Figs. 5 and 6, Fig. 8 shows a sequence diagram am to illustrate the operation of the functions included in Figs. 6 and 7, Figs. 9-13 schematically show some examples of post-handling according to the invention.

Description of embodiments.

Fig. 1-3 illustrate data and operational support views for a network element 102, included in a data network, which in the present example is assumed to be part of a telecommunication system. The data network is shown as containing an operational support system for operation and maintenance of the network, represented by a block 104. The block 104 is also intended to represent external users, as will be apparent from the following.

The network element 102 contains in a resource layer 106 resources 108 in the form of hardware and software. The resources 108 may include network element functions, each of which provides. . . . . . u- wv; v. = «.. w. ... i v 1 ... f .H H- 1- .H nu «ß - .n. u -. u 5- n »6 a service in the network, as well as other resources, which are used for the implementation of the network element functions.

For the operating support system and external users, there are two different views / protocols consisting of software. Both views represent the same resources, but one shows an operating support view and the other a file management view. Interfaces for operating support and file management are indicated at 110 resp. 112.

In the first case, it is assumed that this is an object-oriented view of the kind, which appears in more detail in Swedish patent 470,456. This document contains concepts that may also have their origins in an international standard called TMN, which refers to the management of telecommunication networks from operating support systems. The TMN standard has been developed by an organization called ITU-TS (International Telecommunication Union for Telecommunication Standardization) and is described in its recommendation M.3010. The ITU-TS recommendations, in turn, are based on international standard recommendations proposed by an international organization called ISO (International Standardization Organization). It should be emphasized, however, that the invention is not limited to use in a network element with an object-oriented operating support view.

In the operating support view, the network element 102 from the operating support system 104 appears to consist of a number of handling objects 114.

The management objects 114 are included in a management information base 116 and are used by the operational support system 104 for managing resources included in the resource layer 106 in connection with the implementation of network element functions. With reference to patent 470,456 and TMN standard, management information database is an abstract concept, and should therefore not be confused with a physical database used to permanently store data in a system.

A file management view is commonly used when transferring large amounts of data from a network element to an operating support system or external user. The data transfer can take place via different protocols depending on which operating support system is used. In the examples that follow, a view via the FTAM (File Transfer, Access and Management) protocol according to the ISO standard 8571 will be used.

In the file management view, the network element 102 for operating support- .f 1 ... u. U »v a s 1, ... . ». , .-. «.., n: n. I .. -. i. »q n. s n. u - -. _. .w 7 the system or an external user as consisting of a number of information identifying entities 118, which can be used by the operating support system or external users to retrieve information from the resource layer 106. The information entities 118 correspond to Virtual File (VF) in FTAM and are therefore denoted by VF in the figures, as well as VF objects continued below. VirtualFile in FTAM is an information entity capable of specifying either the origin or destination of a sequential data transfer. However, in the present case, the VF objects 118 are part of a file server entity 120, which consists of software which realizes a file management view of resources included in the resource layer 106. The file server entity 120 can therefore be said to have the character of VirtualFileServer, and is therefore denoted by VFS in the figures, and VFS objects continued below. Although only such a VFS object is shown in Figs. 1-3, a number of different such VFS objects can be used in a system.

The term.VFS = VirtualFileServer in the present context should not be confused with VFS = VirtualFileStore in FTAM, which corresponds essentially to the union of all VFs, as such a number of VFSs in the sense of VirtualFileServer show.

For further details regarding VFS = VirtualFileStore and VF, please refer to the above-mentioned standard ISO 8571.

As a characteristic part of the invention, the resources 108 in the resource layer 106 comprise a first software function 122, forming a communication function, which is intended to retrieve and provide existing information in the resource layer 106 for post-handling on request from the operating support system or an external user. The communication function 122 is represented in the file management view by VFS 120. As another characteristic part of the invention, the resource layer 106 also includes a second software function 124, forming a transformation function, which communicates with the communication function 122 and is intended for receiving information retrieved as above and to is handled by the communication function 122. The transformation function 124 transforms this information into an external format required by the customer in a post-handling process.

The two functions 122 and 124 identified above can be said to form main components of a general support function for outputting and post-processing data in a computer system, which will henceforth also be called GOPS, which stands for "Generic Output and Postprocessing Support". GOPS is a tool that enables an operator to transform / format data in records to external formats. Data can then be output to a user via file transfer or other external communication, such as tape, printer, etc., which is available in the current system.

The transformation itself will henceforth be called GPP, which stands for "Generic Post Processing", ie. general finishing. The term GPP will also be used for function 124. GPP consists of an arbitrary number of transformation components, defined in more detail below, which perform transformations of data. GPP enables an application / market to implement suitable transformation components, and reuse and modify transformation components during runtime. Adaptation to the existing standard is also possible.

By transformation component is thus meant here a function which transforms data. As will be described in more detail below, transformation components can be linked together to form a pipeline, which in turn constitutes an application of GPP. Each transformation component is intended to have the same input / output interface. The transformation of data into transformation components is highly application / market dependent.

In other words, the GOPS support function is a common name for functions that retrieve and output information, e.g. from a system log, and should be able to be used in different ways to suit applications and markets. An example is the formatting and output of TT (Toll Ticketing) items, ie. billing data in mobile telephony, stored in logs in an internal format.

Fig. 1 is mainly intended to illustrate in general the connection between operating support, data and resources in the network element 102. The information in the resource layer 106 is not in file format and must therefore be transformed by GPP 124 before it is presented to the operating support system or an external user. The GPP should also provide an operational support view of the transformation, which is indicated by it being displayed as represented by a management object 126 in the management information base 116.

Fig. 2 illustrates in a similar view as in Fig. 1 schematically the structure of the GPP function. For this end purpose, a block 202 designated R_GPP (R: Resource) is an enlarged view of the GPP function 124 included in the resource layer 106. In this view, a chain 204 of transformation components is indicated.

Fig. 3 is also intended to schematically illustrate how GOPS can be regarded as something which connects the VFS view, the transformation and the operating support view, and thereby connects and controls the output of data. In the figure, a block 302 designated FMA_GOPS (PMA: FileManagementAdaptation) is an enlarged view indicating a GOPS function. View 302 is positioned as covering VFS / VF 120/118 to indicate that GOPS is represented by VFS 120 in the file management view. In the operation support view, the GOPS function 302 is represented by a handling object MO_GOPS (M0: ManagedObject) designated 304. Sight lines 306 from the function 122 in the resource layer 106 to the block 302 also include the view 202 of the GPP to indicate that in addition to the function 122 the function GPP 124 is also included. and GOPS.

Since Figs. 1-3 are assumed to relate to the use of file transfer according to FTAM as an example, the file management view includes a "responder" according to FTAM, indicated by FTAM_Responder in a block 308. The corresponding "initiator" according to FTAM, indicated by FTAM_initiator in the block is included in block 104, and may thus be the operation management system or an external user.

According to the definition specified in FTAM, the responder is a "file service user", ie. file service user, which accepts "FTAM regime establishment", requested by initiator. A "file service user" is defined as a part of an application, which conceptually invokes the FTAM service, and as initiator a "file service user", which requests "FTAM regime establishment ”.

In ISO 8571, e.g. in the first part 8571-1: 1988 on p. 17 and 18, a summary is given of the file service and its support protocols, in which it is stated e.g. The role of FTAM_Responders in establishing the “FTAM regime.” Annex A in the same section includes some examples, in the form of sequence diagrams, of the use of FTAM.

GOPS 302 thus has representations 304 and 120 in the operating view respectively. the file management view, thereby connecting the file management view, the transformation function 124 and the operating support view so that a data record managed by the GPP function can be transferred to the operating support system or an external user.

Fig. 4 contains an enlargement of the view 202 in Figs. 2 and 3 and at the same time schematically indicates the communication between the functions 122 and 124. An origin 402 for data in the function 122 is connected via an interface 404, transformation components 406.1-406.4 and intermediate interfaces 408.1 -408.3, and an additional interface 410 to a destination 412 for the data.

The number of transformation components shown and existing interfaces in between are used only as examples. An arbitrary number is thus possible.

Each of the transformation components 406.n has a role or sub-task.in a data processing in the transformation function 124. One or more of the transformation components 406.1-406.4 can be said to realize a specific processing step or use case in the system according to Fig. 4. A collection of interrelated such use case forms a function which may form part or all of the transformation function 124.

Each transformation component 406.n executes a program component in the form of a load module, which contains one or more program units, each of which may consist of a separately compilable source code set. The application units implement and use the 408.n interfaces.

Each of the interfaces 408.n consists of a collection of type definitions and definitions of two role definitions for each transformation component.

An example of an interface is a function prototype, F, with associated role definitions. The role definitions must specify the semantics of the function call, ie. what is expected of the caller and what the function is expected to do. If a program unit A provides a. matching function, it is natural to say that A implements F. In the same way, it is natural to say that a program unit B, which only uses F to call the function, uses F.

It is not difficult to find examples of interfaces, where it is less obvious which side uses the interface and which implements it. In such cases, it is the role definitions that determine the concrete meaning of the terms use and implement.

To produce a program component, a number of compiled program units are linked together. In that process, most interfaces will be assigned a unique implementation and all uses of such interfaces within the application component will be statically linked to this implementation. When a program component is loaded into a processor, some of its interfaces will be linked to a unique implementation.

The interfaces that then remain are called open and are of particular interest here. A loaded software component is characterized by which open interfaces it implements and which it uses.

Before a program component can be used in a use case, the use of its open interface must be defined. A program component that has at least one open interface provides a set of abstract connection points. Each abstract access point uses or implements one of the open interfaces.

For a given use case, certain program components are mandatory. If the mandatory program components contain open interfaces, they must be provided with configuration information that makes it possible to link users' with implementation for each open interface.

A use case is configured as follows.

The first step is to select the program components to be included. When this has happened, a set of open interfaces has also been obtained. The next step is to decide, for each of the program components, which transformation component or components it should occupy in the current use case. When this has happened, for each transformation component there is a concrete connection point corresponding to each abstract connection point in its program component. The last step is to pair users and implementation for all concrete connection points. Obviously, two concrete connection points can only. are paired by the corresponding abstract connection points one uses and the other implements the same open interface.

In a simple use case, the interfaces 404-410 may be of a type referred to herein as Offer / Accept (O / A). More specifically, it is a method call interface, the name of which is due to the fact that sacrifice and acceptance are the main methods used for communication. Furthermore, when two objects communicate via the interface, one should have the role of “source” and the other the role of “sink.” The data flow across the interface runs from source to sink.

The origin 402 is associated with a general interface 403 in the function 122, which allows the transfer of arbitrary records to the GPP function 124 for transformation.

Destination 412 is associated with a general file transfer interface 413, which allows data to be transferred to any transfer or other mode of transport.

The chain of transformation components 406 may form a pipeline, e.g. similar to the UNIX pipeline concept.

The difference is that the Offer / Accept interfaces allow the transformation components to execute in the same process so that the cost of handling is minimized. The Offer / Accept interfaces operate in both directions, contain flow control and copier data. The transformation components must by definition be users of this interface.

The described concept for the transformation function 124 entails for the designer and the operator the following advantages and possibilities: - arbitrary data transformation, ie. not just formatting, - arbitrary file transfer protocol or other file management (tape, printer, etc.), - maximum amount of general functionality, ie. a high level of design support, - a minimum of design and implementation for the application, - reuse of redesigned transform components, - possibility to change transformation components in a working system, but not during a file transfer, 515 343 13 - possibility to adapt to standard, existing and future , by adding transformation components, - the ability depending on the market or application requirements to be able to deliver records and files in any format.

The GPP post-management function is an abstract resource object with predefined methods and parameters, but the actual management within the object is application-specific.

GPP can thus be considered as a box, in which it is possible to introduce various data transformations as long as established rules for transformation components are followed. These are that the transformation components must partly use a fixed interface, such as the O / A interface, and partly have input and output types, where the output type of one transformation component must match the input type of the next transformation component in the pipeline.

Some markets / users may require flexibility in terms of formats and / or transformations and others in terms of efficiency in the transformation. The requirements are somewhat contradictory, but both can be met. If a fixed format efficiency is desired, a transformation component can be constructed with optimized code for that specific format. If flexibility is desired, a library of selectable transformation components is constructed.

In order to be able to utilize a maximum of general functionality, it is required that analysis takes place of where the information content must be known, and where one moves with data. In most cases, this is data, ie. a container of bits to be transported, stored, transmitted, etc. As long as data is concerned, general functions can be used, as soon as. in the case of information, the function must be specialized.

Preferably, the GPP function is constructed from the beginning with a basic transformation component. The reason for this is that the constructor of the GOPS function cannot know which formats different users / markets want for their information. Consequently, it is the application / market designer who must then specialize this component for the desired purpose. As an example, an operator may adapt the format of the records to a database format 515 345 14 used in a local finishing system. This is possible by specializing the basic transformation component.

Here, by way of example, a schematic account will be given with the aid of Figs. 5-8, and on the basis of the construction of a network element described with reference to Figs. 1-3, for how the GOPS function 122 in Figs. 1-3 can be used for retrieving and outputting information. "Retrieval" refers to this example of retrieving information from a log.

If no formatting or other data management is performed, it is the internal format that is transferred. This property is useful, for example, if the managed information is transformed outside the system. In this case, the GOPS function provides support for outputting log entries as virtual files.

Fig. 5 indicates how an information generating object 502 sends a notification 504 to a log 506, where it is stored as a log record. From the log 506 the log record can now be retrieved by GOPS 122, which after formatting and handling it, forwards the information packet thus obtained according to arrow 510.

Notifications can be considered as information carriers. The TMN standard defines a support object called EFD (Event Forwarding Discriminator) as a collector of notifications, but notifications can also be collected in logs for intermediate storage.

Notifications can be of two types, namely management object notifications or resource notifications. The log can subscribe to both types of notifications. Notifications must be formatted and handled before output.

Notifications are stored as log entries and the log entries are retrieved from the log.

Mass data, i.e. not individually selected data, should be transferred as files for capacity reasons, but each application can choose any file transfer, which is available in the network element.

Formatted entries are output via a general interface. The file transfer protocol is an independent interface. The output interface is generally in the sense that the same methods and parameters will be used by all objects that can be selected for output when setting up GOPS. The file format belongs to the selected output object. As an example, one object as in the present example may be an implementation of FTAM, and another of FTP. The general interface supports the same methods for both implementations.

Fig. 6 illustrates the principles of operation of the GOPS function in the example of Fig. 5. The figure is horizontally divided into three sections, namely an operating support management view 602 via the interface 110, a view 604 of a part of the resource layer 106 (Fig. 1 ), and a file management view 606 via the interface 112 (Fig. 1). Dashed vertical dividing lines between the three views are denoted by 608 resp. 610. The management view 602 contains the management object 304 for the GOPS function 122 in the resource layer 106 (Figs. 1 and 3). In addition to function 122, view 604 includes log 506 and GPP function 124 (Figs. 1-3). The file management view 606 includes the representation 120 (Fig. 1) of the GOPS function 122 as well as the FTAM_Responder 308 (Fig. 3).

Referring also to the sequence diagram in Fig. 8, Fig. 6 illustrates how a request is sent, arrow 802, via the responder 308 included in the file management view, arrow 614, to obtain one or more log entries from the log 612. The request originates from an initiator, according to above represented by block 104 in Figs. 1-3. The request is forwarded, arrow 616, via the GOPS representation 120 to the GOPS function 122. The GOPS function 122 sends a request according to the arrow 617 to obtain the current log entry (s) from the log 612. The log entries are sent to the GOPS function 122 according to arrow 618 and forwarded by the latter to the GPP function 124 with request, arrow 620, for finishing, i.e. transformation to the format desired by initiator 104. The GPP function 124 performs the requested transformation and sends, arrow 622, the data thus processed, e.g. in the form of files, to the GOPS function 122. The GOPS function 122 sends, arrow 624, the files further via the GOPS representation 120 and responder 308, arrow 626. Via responder 308, the files finally reach initiator 104, according to arrow 804 (fig. 8).

In the example described, initiator 104 can be an arbitrary actor, e.g. the operating support system, a billing center, etc. The post-processed data obtained from the GOPS function 122 can, however, in addition to via file transfer, 515 343 16 e.g. via FTAM as described above, is also output through other external communications, such as tapes, printers, etc., that are available in a current system.

The GOPS_MO representation 304 (Fig. 3) in the operation support view of the GOPS function 122 is set up when a system such as that in Fig. 6 is started. Through Representation 304, the operational support system * establishes and controls the rules for what shall apply in this system. Thus, it is determined as an example which logs are to be used, how the GPP function is to be structured, ie. the number and nature of its transformation components, which rules apply to communication with an external user, e.g. the rules for file set in the example of Fig. 6.

Fig. 7 illustrates an example of a scenario according to Figs. 5 and 6, constituting a case in mobile telephony where a billing center subscribes trafik to traffic data, so-called TT (Toll Ticketing) records, which are stored in logs in an internal format. With the help of GOPS and via FTAM, the invoicing center receives this traffic data. Fig. 7 shows a network element 702 containing traffic information generating objects 704.1-704.n, which may represent mobile telephony subscribers, an operating support system 706, a log 708, and an intermediate storage memory 710. Furthermore, the file server GOPS-VFS 120, GOPS function 122, GPP function are indicated. 202, and FTAM responder 308.

The billing center forming an external user is denoted by 712, and contains FTAM + initiator 104.

Via the operating support system 706, traffic data is stored from the objects 704 in the log 708. The traffic data, to which the invoicing center 712 subscribes, are then temporarily stored in the memory 710.

During 'low-traffic time', the invoicing center 712 retrieves the intermediate storage traffic data from the memory 712 via the log 708.

The communication and the process take place in the same way as described for Figs. 6 and 8, so that the arrows inserted in Fig. 7 have received the same reference numerals as the corresponding arrows in Figs. 6 and 8.

Referring also to the sequence diagram in Fig. 8, Fig. 7 illustrates how a request is sent, arrow 802, from FTAM initiator 104 to FTAM responder 308 to obtain one or more log entries from log 708. Request forwarded, arrow 614 , via the GOPS representation 120 to the GOPS function 122, arrow 616.

The GOPS function 122 sends a request according to arrow 617 to obtain the current log record (s) from the log 608. The log records are sent from the cache 710 via the log 708 to the GOPS function 122 according to the arrow 618. The log records are forwarded by the GOPS function 122 to GPP function 124 with request, arrow 620, for finishing, ie. transformation to the format desired by initiator 104. The GPP function 124 performs the requested transformation and sends, arrow 622, the data thus processed, e.g. in the form of files, to the GOPS function 122. The GOPS function 122 sends, arrow 624, the files on via the GOPS representation 120 and responder 308, arrow 626. Via responder 308, the files finally reach initiator 104 in the billing center 712, according to arrow 804 .

In the following, with reference to Figs. 9-12, a number of further examples are given in the form of a driving time view of finishing by means of the GPP function.

Fig. 9 is substantially identical to Fig. 5, so the same reference numerals as in Fig. 5 are used where applicable.

Briefly, an information generating object 502 sends a notification 504 to a log 506, where it is stored as a log record. From the log 506, the log record is retrieved by GOPS 508, which after formatting and handling the GPP function, denoted by 902, forwards the information packet thus obtained according to arrow 510.

The purpose of Fig. 9 is to illustrate that the post-processing is developed to minimize the need to deal with information and that when the need arises make these occasions / functions as flexible as possible. The structure and content of the information need to be known in a few defined places, indicated by an oval 904 in Fig. 9 as well as in Figs. 10-13. Thus, in Fig. 9, such an oval 904 is present in the information generating object 502 and in the GPP function 902. The GPP function is shown in Fig. 9 as intended for handling immediately before output, but could just as well be used before logging (not shown).

A market may require the same record delimiter for different types of records and therefore it may be useful to implement these as a separate object for reuse. This feature can be further developed to provide a layered support structure for post-handling. Referring to Fig. 10, a GPP function 1002 may include, for example, a transform component 1004 for opening an information packet incoming at 1006, a transform component 1008 for translating tags into market-specific tags, a transform component 1010 for formatting, and a transformation component 1012 for mail delimitation. Additional, not shown examples of data for transformation components are sorting records according to a desired order, aggregating tables, compiling records from instrument readings, etc. The internal structure of the GPP function allows the use of 0-n separate functions and thus the reuse of application objects .

Fig. 11 is intended to illustrate an example where a log 1101 has collected information from persistent objects in notifications, which is to be processed by a GPP function 1102 included in a GOPS function 1104. In the GPP function 1102, the notifications of a transform component 1106, is compiled and formatted by a transform component 1108, and post-delimited by a transform component 1110. The result is then output, arrow 1112, by the GOPS function 1104 in file format 1114.

It is possible to transform data in several steps, depending on the purpose of the transformation. Fig. 12 is intended to illustrate as an example a possible security management scenario.

An object 1202 adds a checksum, arrow 1203, to a security notification 1204, which is then logged as a log entry 1205 in a log 1206. From the log 1206, the log entry 1205 is retrieved by a GOPS function 1208. In a GPP function included in the GOPS function 1208 function 1210, formatting of a transformation component 1212, encryption of a transformation component 1214, and mail delimitation of a transformation component 1216 are performed. The result is sent from the GOPS function 1208 in file format 1218.

It is also possible to optimize in different ways to achieve flexibility or capacity / throughput. Fig. 13 is intended to show as an example a possible invoicing management scenario. 515 543 19 From a call recorder output 1302, a logging notification 1304 is sent as a log record in a log 1306. From the log 1306, the log record is retrieved by a GOPS function 1308. The GOPS function 1308 includes a GPP function 1310. Off a transformation component 1312 included in the GPP function 1310 is transformed into code optimized for a specific market and application. v

Claims (15)

4- 1.; - 515 343 Éifïgï fi i-f 20 Network elements included in a computer network with an operational support system (104) for operation and maintenance of the network, comprising a resource layer (106) containing resources in the form of hardware and software, including network element functions, providing services in the network, as well as resources used for network element functions implementation, a software operating operation view (110), in which the network element (102) from the operating support system (104) appears to consist of a number of resource representations (114) and is used by the operating support system for managing the respective resource and network element function in connection with implementing a network element function, a software file view (112) consisting of software, where the network element from the operating support system (104) or an external user (712) appears to consist of a number of data file identifying objects (118, 120) which can be used by the operating support system. for data file transfer in the resource layer to a resource that can be used by an external user, feel characterized in that a support function existing in the resource layer (122, 124) comprises a communication function for communicating with a user, and on request retrieving and providing data existing in the resource layer, and a transformation function for transforming this retrieved data into a desired format. , and that the communication function (122) is represented by a management object (304) in the operating support view (110) and by a data file identifying object (120) in the file management view (112) to thereby connect the file management view (112), the transformation function (124) and the operation support view (110) so that a data file transformed by the transformation function (124) can be transferred to a resource utilized by an external user (712). Mesh element according to Claim 1, characterized in that the transformation function comprises a number of transformation components intended for each type of transformation. Network element according to Claim 2, characterized in that each of the transformation components has a role or sub-task in a data processing in the transformation function. Mesh element according to claim 3, characterized in that one or more of the transformation components realizes a specific processing step or use case, wherein a collection of mutually related such use cases forms a function which can form part or all of the transformation function. Network element according to one of Claims 2 to 4, characterized in that each transformation component executes a program component in the form of a charging module which contains one or more program units, each of which may consist of a separately compilable amount of source code. Network element according to claim 5, characterized in that the program units implement and use interfaces, which consist of a collection of type definitions and two role definitions for each transformation component_ A method of transmitting data in a network element to a desired format, which network element is part of a data network with an operating support system (104) for operation and maintenance of the network, comprising a resource layer (106) containing resources (108) in the form of hardware and software, including network element functions, providing services in the network, as well as resources used to perform the network element functions, a software operating operation view (110), in which the network element (102) from the operating support system (104) appears to consist of a plurality of resource representations ( 114) and is used by the operating support system for managing the respective resource and network element function in connection with the implementation of a network element function, a file management view consisting of software (112), where the network element from the operating support system (104) or an external user (712) appears as existing of a number of data file identifying objects (118, 120) which can be used by the data file transfer operation support system in the resource layer to a resource that can be used by an external user, characterized in that a process is started on request, which comprises that data existing in the resource layer is retrieved and provided by a communication function, which sends this data to be transformed into the desired the format of a transform function, which returns the transformed data to the communication function for forwarding to the desired instance, the communication function (122) is represented by connecting the file management view (112), the transformation function (124) and the operation support view (110) by the communication function is represented by a management object (304) in the operating support view (110) and by a data file identifying object (120) in the file management view (112) so that a data file transformed by the transformation function (124) can be transferred to a resource used by an external user (712) . Method according to claim 7, characterized in that in order to obtain data in the desired format, a user sends a request thereto to the network element, which starts a corresponding process, which comprises that the request is forwarded to the communication function, the communication function retrieves basic data corresponding to said data in the desired format, from a resource included in the resource layer, which contains this basic data, and sends this basic data to the transformation function with request for transformation to the desired format, the transformation function performs the requested transformation and sends the thus processed data to the communication function, which forwards them to the external user. Method according to claim 8, characterized in that the transformed data is transmitted from the network element to the user via file transfer or through other external communication. Method according to claim 8 or 9, characterized in that the process is started by setting up a representation for the communication function in the operating support view, via which representation the operating support system determines and controls the rules for what shall apply to carry out the process. Method according to claim 10, characterized in that the rules n .. 515 543 23 include regulations for which basic data-containing resources are to be used, how the transformation function is to be structured, and which rules apply to communication with the user. Method according to one of Claims 7 to 11, characterized in that basic data is retrieved from a log, and that transformation takes place before or after logging. Method according to one of Claims 7 to 12, characterized in that basic data is obtained from a notification. Method according to one of Claims 7 to 13, characterized in that the transformation is carried out by the transformation function by means of a number of transformation components intended for each type of transformation. Method according to claim 14, characterized by the use of one or more transformation components to carry out any resp. some of the following transformations: opening an incoming information packet, containing the said basic data, translating tags into market-specific tags, formatting, data record delimitation, sorting records according to a desired order, aggregating tables, compiling records from instrument readings, encryption, transformation to code optimized for a specific market and application.