Device based automated tool integration for lifecycle management platform

A device may identify a tool operating on a first device for integration into a lifecycle management platform operating on a second device. The tool may be associated with providing a functionality not included in the lifecycle management platform. The first device may be external to the second device. The device may determine a set of tool attributes for data events associated with the tool. The data events may include a data input, a data output, a new message, an updated message, a deleted message, or the like. The device may select a message format based on the set of tool attributes. The device may configure adaptation for a tool application programming interface (API) of the tool and a platform API of the lifecycle management platform based on the message format. The device may provide information associated with configuring adaptation for the tool API and the platform API.

This application claims priority under 35 U.S.C. § 119 to India Provisional Patent Application No. 201641012824, filed on Apr. 12, 2016, the content of which is incorporated by reference herein in its entirety.

BACKGROUND

A software development project may include activities such as computer programming, documentation, testing, and bug fixing involved in creating and maintaining a software product. In performing software development, various methodologies may be employed, including agile development, which typically emphasizes speed and flexibility through the collaborative effort of self-organizing cross-functional teams. In such a development project, a provider may provide a lifecycle management platform that incorporates applications to assist with and/or automate development, such as agile development applications, application delivery applications, application maintenance applications, or the like.

SUMMARY

According to some possible implementations, a device may include one or more processors. The one or more processors may identify a tool operating on a first device for integration into a lifecycle management platform operating on a second device. The tool may be associated with providing a functionality not included in the lifecycle management platform. The first device may be external to the second device. The one or more processors may determine a set of tool attributes for data events associated with the tool. The data events may include a data input, a data output, a new message, an updated message, a deleted message, or the like. The one or more processors may select a message format based on the set of tool attributes. The one or more processors may configure adaptation for a tool application programming interface (API) of the tool and a platform API of the lifecycle management platform based on the message format. The one or more processors may provide information associated with configuring adaptation for the tool API and the platform API.

According to some possible implementations, a method may include receiving, by a device, a message for adaptation between a first format associated with a tool operating on a first device and a second format associated with a lifecycle management platform operating on a second device. The lifecycle management platform may include a set of functionalities associated with managing resources for a development project. The tool may include a functionality associated with managing resources for the development project that is not included in the set of functionalities. The method may include identifying, by the device, a tool adapter including a set of rules for adapting messages between the first format and the second format. The tool adapter may be stored in an archive of tool adapters. The method may include determining, by the device, whether the message is from a trusted or untrusted source. The method may include selectively performing, by the device, adaptation of the message between the first format and the second format using the set of rules included in the tool adapter to generate an adapted message based on a result of determining whether the message is from a trusted or untrusted source. The message may be adapted when from the untrusted source. The message may be bypassed from adaptation when from the trusted source. The method may include outputting, by the device, the adapted message.

According to some possible implementations, a non-transitory computer-readable medium may store one or more instructions. The one or more instructions, when executed by one or more processors, may cause the one or more processors to identify a tool operating on a first device for integration into a lifecycle management platform operating on a second device. The tool may be associated with providing a functionality not included in the lifecycle management platform. The one or more instructions, when executed by one or more processors, may cause the one or more processors to determine a set of tool attributes for data events associated with the tool. The data events may include a data input, a data output, a new message, an updated message, a deleted message, or the like. The one or more instructions, when executed by one or more processors, may cause the one or more processors to select a message format based on the set of tool attributes. The one or more instructions, when executed by one or more processors, may cause the one or more processors to configure adaptation for a tool application programming interface (API) of the tool and a platform API of the lifecycle management platform based on the message format. The one or more instructions, when executed by one or more processors, may cause the one or more processors to store a tool adapter associated with configuring adaptation for the tool API and the platform API. The one or more instructions, when executed by one or more processors, may cause the one or more processors to receive, after storing the tool adapter, a message. The one or more instructions, when executed by one or more processors, may cause the one or more processors to determine that the message is associated with the tool. The one or more instructions, when executed by one or more processors, may cause the one or more processors to obtain the tool adapter from an adapter archive. The one or more instructions, when executed by one or more processors, may cause the one or more processors to adapt the message, using the tool adapter, to generate an adapted message. The one or more instructions, when executed by one or more processors, may cause the one or more processors to output the adapted message to facilitate communication between the tool and the lifecycle management platform.

DETAILED DESCRIPTION

A provider may provide a lifecycle management platform operated in a cloud computing environment to provide end-to-end assistance and/or automation for a development project. However, other tools that are not included in the development project may be useful to integrate, such as defect tracking tools, ticket management tools, or the like.

In such a development project, some tools may be hosted by the provider in a secure portion of a tool integration platform, while other tools may be hosted by a client who uses the lifecycle management platform but wants to also use another application. In this case, the other tools may utilize different data formats than the lifecycle management program. For this reason, integrating the other tools into the lifecycle management program (e.g., to allow the tools of the lifecycle management platform and the other tools to communicate and interoperate) has conventionally required manual coding of interfaces.

Implementations, described herein, provide a tool integration platform that provides automatic adaptation of data formats for a lifecycle management platform and other tools that are to integrate into the lifecycle management platform. In this way, the tool integration platform reduces the time to integrate each tool, thereby improving management of projects, which reduces computing usage by reducing errors, time to resolve errors, effort spent to develop and/or manage a project, or the like, relative to a manual integration approach. Also, as a result, tools need not be cohosted with the tool integration platform because the tool integration platform adapts messages from tools to a format that the lifecycle management platform can use, and maintains security protocols associated with the tool integration platform and/or another computing environment in which other tools are hosted.

FIGS. 1A and 1Bare diagrams of an overview of an example implementation100described herein. As shown inFIGS. 1A and 1B, example implementation100includes a ticket tracking tool, a tool adapter operated by a tool integration platform, and a lifecycle management platform. A provider may provide the lifecycle management platform, and a client may provide the ticket tracking tool. In some implementations, the tool integration platform may receive a request to adapt the ticket tracking tool for the lifecycle management platform, and may generate a tool adapter. The tool adapter may permit the tool integration platform to integrate the ticket tracking tool into a user interface of the lifecycle management platform to provide seamless use of the ticket tracking tool when using the lifecycle management platform. For example, the tool integration platform may identify a set of data transformations, application programming interface (API) call transformations, user interface element layout transformations, or the like that permit information, functionalities, and/or user interface elements of the ticket tracking tool to be integrated into the lifecycle management platform. In this way, the tool integration platform reduces a quantity of user interfaces to operate and/or to be utilized, and increases security by allowing for a single sign-on.

As shown inFIG. 1A, and by reference number110, the tool integration platform (e.g., a tool adapter operated by the tool integration platform) may receive a ticket message (e.g., a published ticket in extensible markup language (XML)) from the ticket tracking tool. As shown by reference number120, the tool integration platform may identify an adapter for the ticket message. For example, the tool adapter may obtain an adaptation tool from an adapter archive of tool adapters based on previously generating and storing the adaptation tool. For example, the tool integration platform may determine that a tool adapter is stored for adapting data associated with the ticket tracking tool to the lifecycle management platform. As shown by reference number130, the tool integration platform may use the adapter to perform adaptation and convert the message to a canonical data model format. For example, the tool adapter may use the adaptation tool to transform the ticket message to the canonical data model format. In some implementations, the tool adapter may transform a text based message, an API call, a user interface element, or the like into a corresponding text based message, API call, or user interface element of the canonical data format based on a set of adaptation rules of the adaptation tool. As shown by reference number140, the tool integration platform may output the adapted ticket message. For example, the tool integration platform may generate and output a JavaScript Object Notation (JSON) message object in the canonical data format (a “COM” format) using a platform API.

As shown inFIG. 1B, and by reference number150, the tool integration platform may receive a ticket response message (e.g., in a JSON format) from the lifecycle management platform. As shown by reference number160, the tool integration platform may identify an adapter for the ticket response message (e.g., stored in an adapter archive). For example, the tool adapter may determine that an adaptation tool is stored to transform the ticket response message in the JSON format into an XML format of the ticket tracking tool. As shown by reference number170, the tool integration platform may use the adapter to perform adaptation and convert the message to the ticket tracking tool format. As shown by reference number180, the tool integration platform may output the adapted ticket message response (e.g., in XML in the ticket tracking tool format using a tool API) to the ticket tracking tool.

Although described herein in terms of a ticket tracking tool, another tool may be integrated into the lifecycle management platform, such as a defect management tool, an agile workflow tool, or the like. In this case, the tool integration platform may generate a tool adapter based on receiving a request to adapt the defect management tool, the agile workflow tool, or the like and may integrate the defect management tool, the agile workflow tool, or the like into a user interface of the lifecycle management platform using a tool adapter.

In this way, the tool integration platform reduces the time to integrate tools into a lifecycle management platform, thereby improving management of projects, which reduces computing usage by reducing errors, time to resolve errors, effort spent to develop and/or manage a project, or the like, relative to a manual integration approach. Also, as a result, tools need not be cohosted with the tool integration platform because the tool integration platform adapts messages from tools to format that the lifecycle management platform can use. This may reduce memory utilization of the tool integration platform and improve data security for the tool integration platform relative to storing all tools for the lifecycle management platform collocated with the lifecycle management platform.

As indicated above,FIGS. 1A and 1Bare provided merely as an example. Other examples are possible and may differ from what was described with regard toFIGS. 1A and 1B.

FIGS. 2A-2Care diagrams of an example environment200in which systems and/or methods, described herein, may be implemented. As shown inFIGS. 2A, environment200may include one or more client devices210(hereinafter referred to individually as “client device210,” and collectively as “client devices210”), which may include a set of tools220a cloud computing environment230, which may include a set of computing resources235and which may host a tool integration platform240, and a network250.

Client device210includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with utilization of a lifecycle management platform. For example, client device210may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device.

Tool220includes one or more tools operated by client device210and integrated into a lifecycle management platform using tool integration platform240. For example, tool220may include a ticket tracking tool, a defect management tool, an agile workflow tool, or the like that provides additional functionalities, a different set of functionalities, or the like relative to the lifecycle management platform. In some implementations, tool220may be stored by and/or operated by client device210. In some implementations, tool220may be stored by and/or provided (e.g., as software-as-a-service) by a tool integration platform, such as tool integration platform240or another tool integration platform. In some implementations, tool220corresponds to the ticket tracking tool described herein with regard toFIGS. 1A and 1B.

Cloud computing environment230includes an environment that delivers computing as a service, whereby shared resources, services, etc. may be provided to integrate tool220into a lifecycle management platform using a tool adapter. Cloud computing environment230may provide computation, software, data access, storage, and/or other services that do not require end-user knowledge of a physical location and configuration of a system and/or a device that delivers the services. As shown, cloud computing environment230may include tool integration platform240. In some implementations, cloud computing environment230hosts the tool adapter described herein with regard toFIGS. 1A and 1B. In some implementations, cloud computing environment230may host the lifecycle management platform. In some implementations, cloud computing environment230may communicate with another cloud computing environment230that hosts the lifecycle management platform (e.g., via network250).

Computing resource235includes one or more personal computers, workstation computers, server devices, or another type of computation and/or communication device. In some implementations, computing resource235may host tool integration platform240. The cloud resources may include compute instances executing in computing resource235, storage devices provided in computing resource235, data transfer devices provided by computing resource235, etc. In some implementations, computing resource235may communicate with other computing resources235via wired connections, wireless connections, or a combination of wired and wireless connections.

As further shown inFIG. 2, computing resource235may include a group of cloud resources, such as one or more applications (“APPs”)235-1, one or more virtual machines (“VMs”)235-2, virtualized storage (“VSs”)235-3, one or more hypervisors (“HYPs”)235-4, or the like.

Application235-1includes one or more software applications that may be provided to or accessed by client device210. Application235-1may eliminate a need to install and execute the software applications on client device210, such as the lifecycle management platform, the tool adapter, or the like. For example, application235-1may include software associated with tool integration platform240and/or any other software capable of being provided via cloud computing environment230. In some implementations, one application235-1may send/receive information to/from one or more other applications235-1, via virtual machine235-2.

Hypervisor235-4provides hardware virtualization techniques that allow multiple operating systems (e.g., “guest operating systems”) to execute concurrently on a host computer, such as computing resource235. Hypervisor235-4may present a virtual operating platform to the guest operating systems, and may manage the execution of the guest operating systems. Multiple instances of a variety of operating systems may share virtualized hardware resources.

As shown inFIG. 2B, tool integration platform240may host, using computing resources235-A and235-B, adaptation module251, which includes one or more external queue end-points252-1and252-2, an external queue processor254, a processing queue256(e.g., a queue, an adapter, etc. to receive data, queue the data for adaptation, adapt the data, etc.), an error log258, and a canonical data model (CDM) queue260; and a lifecycle management platform270, which includes a set of native tools272(e.g., tools that comprise the lifecycle management platform270). Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

As further shown inFIG. 2B, non-trusted data in a CDM format (also referred to as a COM format) or a RAW format (e.g., a format associated with a particular tool220that is different from the CDM format) may be received by tool integration platform240at external queue end-point252-1. For example, external queue end-point252-1may receive data from tools220that are not co-located with tool integration platform240, that are not in a CDM format, that are not co-located in a trusted portion of cloud computing environment230, or the like. In contrast, external queue end-point252-2may receive data that is associated with the CDM format and is directed from a trusted source, such as a source that is co-located with tool integration platform240in a trusted portion of cloud computing environment230. In this case, the data may include information, function calls, API calls, messages, objects, user interface elements, etc. that may be transferred from tool220to lifecycle management platform270. For example, a message dispatcher of lifecycle management platform270may provide a message as data to a tool220(e.g., which may be adapted to a format compatible with tool220) to cause an API call to be performed using an API of tool220, thereby permitting lifecycle management platform270to control functionality of tool220. In some implementations, external queue end-point252-2may be provided data via a client API. Data from external queue end-points252-1and252-2may be provided to external queue processor254, which may determine a format of the data, a trust value associated with the data (e.g., whether the data is trusted or untrusted), or the like. In some implementations, tool integration platform240may provide a synchronous response based on receiving data (e.g., the non-trusted data in the CDM format, the data in the raw format, etc.).

For trusted data in a CDM format, external queue processor254may provide the trusted data in the CDM format to CDM queue260without adaptation being performed (e.g., the data is already in a format compatible with lifecycle management platform270). For untrusted data and/or data in a RAW format (e.g., a format of tool220that is not the CDM format), external queue processor254may provide the untrusted data and/or the data in the RAW format to processing queue256for adaptation. Processing queue256may be a tool adapter that corresponds to the tool adapter described herein with regard toFIGS. 1A and 1Band may process the untrusted data and/or the data in the RAW format. Although described herein in terms of a particular order of operations performed on data (e.g., data received at external queue processor254, data received at processing queue256(an adapter) for adaptation, etc.), other orders of operations may be possible. For example, an adapter may be located, in a data flow, at a different position, such as at an external queue end-point252, before an external queue end-point252, or the like). The tool adapter may perform validation, properties mapping, or the like, on the data to determine that the data is associated with a source that satisfies security criteria associated with lifecycle management platform270. Additionally, or alternatively, the tool adapter may provide error information to an error log258. Additionally, or alternatively, the tool adapter may adapt the data into the CDM format, and may provide the adapted data to CDM queue260. Data may be provided from CDM queue260to lifecycle management platform270(e.g., using a CDM router), to permit lifecycle management platform270to utilize the data. In this way, a data from a tool220is integrated into lifecycle management platform270.

As shown inFIG. 2C, adaptation module251may receive, at CDM queue260data in a CDM format from lifecycle management platform270. CDM queue260may determine a destination format for the data. For data that is intended for a tool220using the CDM format, CDM queue260may provide the data to external queue processor254for output to client device210and tool220. For data that is intended for a RAW format (e.g., another type of format), CDM queue260may provide the data to processing queue256, which may adapt the data into the RAW format. In some implementations, processing queue256may output error information to error log258. Processing queue256may provide the adapted data to external queue processor254, which may output the CDM data via external queue end-point252-2and the RAW data via external queue end-point252-1. Although described herein in terms of a particular data flow, other data flows may be possible. For example, data may be received at another queue (e.g., external queue end-point252, provided to external queue processor254, processing queue256, and/or the like to export data generated by lifecycle management platform270.

The number and arrangement of devices and networks shown inFIGS. 2A-2Care provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices than those shown inFIGS. 2A-2C. Furthermore, two or more devices shown inFIGS. 2A-2Cmay be implemented within a single device, or a single device shown inFIGS. 2A-2Cmay be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment200may perform one or more functions described as being performed by another set of devices of environment200.

FIG. 4is a flow chart of an example process400for configuring tool adaptation. In some implementations, one or more process blocks ofFIG. 4may be performed by tool integration platform240. In some implementations, one or more process blocks ofFIG. 4may be performed by another device or a group of devices separate from or including tool integration platform240, such as client device210.

As shown inFIG. 4, process400may include identifying a tool for integration into lifecycle management platform (block410). For example, tool integration platform240may identify tool220for integration into lifecycle management platform270.

In some implementations, tool220may include a ticket management tool, a defect management tool, or the like. In some implementations, tool integration platform240may receive information identifying tool220from client device210(e.g., based on a client providing input to client device210to indicate that tool220is to be integrated, based on monitoring for a new tool release from a tool developer, etc.). In some implementations, tool integration platform240may monitor client device210to identify a new tool220installed on client device210, an upgrade to a tool220installed on client device210, a downgrade to a tool220installed on client device210, or the like. For example, tool integration platform240may scan client device210to determine a status of tools220associated with or previously associated with client device210. In some implementations, tool integration platform240may store a tool profile identifying a set of tools220associated with a particular client device210. In this case, when tool integration platform240detects another client device210associated with a common corporate network, a common Internet protocol address, a common geographic location, a common user, etc. with the particular client device210, tool integration platform240may identify a set of tools of the other client device210based on the tool profile of the particular client device210.

In some implementations, tool integration platform240may search an adapter archive to determine that an adapter has not already been created for tool220. If tool integration platform240identifies a version of an older tool, such as where tool220is a new release, tool integration platform240may automatically operate tool220to generate data for an older adapter to determine whether the older adapter works for the new tool. In this case, tool integration platform240may reconfigure an existing adapter rather than configuring a new adapter. In this way, tool integration platform240may reduce adapter generation time, processing utilization, memory, etc., relative to configuring a new adapter. In some implementations, tool integration platform240may provide a user interface to permit a user to locate an adapter in an adapter archive. In this case, tool integration platform240may utilize machine learning trained based on user use of the user interface to train the machine learning to locate adapters in the adapter archive, thereby reducing a time to train the machine learning relative to another technique that does not train based on user use.

In some implementations, tool integration platform240may identify tool220based on determining a functionality of lifecycle management platform270, such as application delivery services functionalities, application maintenance services functionalities, agile delivery services functionalities, or the like. For example, tool integration platform240may determine that lifecycle management platform270does not include a ticket tracking functionality, and may determine to generate a tool adapter for use in a development project that is to include ticket tracking. Application delivery services may include release management, requirement management, deliverable/receivable management, defect management, test management, work request management, risk management, and/or issue management. As another example, application maintenance services may include work request management, risk management, issue management, incident ticket management, service request ticket management, and/or problem ticket management. As another example, agile delivery services may include risk management, issue management, story management, iteration management, task management, and/or impediment management.

As further shown inFIG. 4, process400may include determining tool attributes for data events associated with the tool (block420). For example, tool integration platform240may determine tool attributes for data events associated with tool220.

In some implementations, the data events may include a data input, a data output, a new message, an updated message, a deleted message, or the like. In some implementations, tool integration platform240may determine capabilities of tool220(e.g., what messages are generated, when messages are generated, the format(s) of the generated messages, etc.), functions of tool220, and/or identifiers associated with tool220(e.g., identifiers of projects in tools, such as may be mapped to identifiers or projects in lifecycle management platform270). In some implementations, tool integration platform240may receive information associated with capabilities of tool220, such as based on user use of a user interface generated by tool integration platform240.

In some implementations, tool integration platform240may automatically run tool220to determine tool attributes. For example, tool integration platform240may communicate with client device210to simulate operation of tool220to determine the set of data events, a data format, a header format, or the like.

In some implementations, tool integration platform240may determine security requirements associated with tool220and the lifecycle management platform270. For example, tool integration platform240may determine whether tool220is operated at a client site, such as a client data center. As another example, tool integration platform240may determine whether tool220is operated in the provider cloud that hosts lifecycle management platform270and/or whether tool220is authorized or non-authorized. In this case, if tool integration platform240determines tool220is operated in the provider cloud and is authorized, tool integration platform240may determine that no further authentication is needed. In contrast, tool integration platform240may determine that authentication is required to verify that the message is from tool220and not associated with a malicious or erroneous purpose (e.g., such as where the message appears to be from tool220, but is not from tool220). In this way, tool integration platform240ensures security for lifecycle management platform270to avoid errors being introduced into a development project that is managed using lifecycle management platform270.

In some implementations, tool integration platform240may determine that tool attribute criteria (e.g., required attributes) are satisfied. For example, tool integration platform240may determine that messages are transmitted in a particular description format (e.g., JSON, or XML).

In some implementations, tool integration platform240may determine that certain attributes are satisfied for each API function of tool220that is to link to an API function of the lifecycle management platform270. In some implementations, tool integration platform240may determine types of criteria that may relate to usage in lifecycle management platform270. For example, tool integration platform240may determine defect management criteria for defect management tools, ticket management criteria for ticket tools, or the like.

In some implementations, tool integration platform240may permit certain attribute values for certain attributes. For example, tool integration platform240may determine that a particular data format associated with tool220for integration allows a particular set of tool values for the certain attribute, such as, in the case of a defect management tool (e.g., permitted values include a critical value and a non-critical value). In this case, tool integration platform240may determine that the lifecycle management platform270is configured to classify information using a different set of lifecycle management platform values (e.g., permitted values include a red value, a yellow value, and a green value), and may generate a set of adaptation rules to convert between the sets of values (e.g., a red value being equivalent to a critical value and a yellow value and green value being equivalent to a non-critical value). In some implementations, tool integration platform240may utilize a machine learning technique to analyze a set of conversions (e.g., a training set of red, yellow, and green values that have already been converted to critical and non-critical attributes), and may generate a rule for adapting values based on applying the machine learning technique to a training set. In some implementations, the machine learning technique may include a pattern recognition technique, a cognitive processing technique, a heuristic technique, or the like. In some implementations, a user may provide, via a user interface generated by tool integration platform240, information identifying the set of conversions. In this case, the machine learning technique may be trained based on the information provided by the user to reduce a time to train the machine learning technique.

In some implementations, tool integration platform240may associate header formats with a pre-defined format readable by tool integration platform240. Otherwise, tool integration platform240may generate another layer of adaptation to adapt header formats. For example, tool integration platform240may generate a layer of adaptation (e.g., a set of rules of a tool adapter) for adapting header information that accompanies a data event between a format that is usable by tool220and a format that is usable by lifecycle management platform270. In this case, one or more of the adaptation rules may relate to rearranging an ordering of data elements of a header from a first ordering to a second ordering.

As further shown inFIG. 4, process400may include selecting a message format based on the tool attributes (block430). For example, tool integration platform240may select a message format based on the tool attributes.

In some implementations, tool integration platform240may determine the message format for tool220based on the tool attributes. In some implementations, tool integration platform240may select XML, JSON, or another description language for transferring a message to lifecycle management platform270. In some implementations, tool integration platform240may select the message format based on a type of information that is provided by tool220.

As further shown inFIG. 4, process400may include configuring adaptation for a tool API of the tool and a platform API of the lifecycle management platform based on the message format (block440). For example, tool integration platform240may configure adaptation for a tool API of tool220and a platform API of lifecycle management platform270.

In some implementations, tool integration platform240may establish mapping of API functions between the tool API and the platform API to permit lifecycle management platform270to control tool220, to perform seamless single login for both tool220and lifecycle management platform270, or the like. In some implementations, tool integration platform240may establish data mapping of data included in tool messages to a canonical data model format that can be used by lifecycle management platform270.

In some implementations, tool integration platform240may configure a user interface to integrate tool APIs. In this case, tool integration platform240may map user interface functions of tool220to pre-defined user interface layouts of lifecycle management platform270(e.g., stored in a data structure).

In some implementations, tool integration platform240may establish identifier mapping of tool identifiers to lifecycle management platform270identifiers. For example, tool integration platform240may utilize pattern recognition, machine learning, heuristics, etc., to identify a same project in tool220and lifecycle management platform270, and to map identifiers. In this case, tool integration platform240may also use a project name, source, client, user, or the like.

FIG. 5is a flow chart of an example process500for performing tool adaptation for a tool. In some implementations, one or more process blocks ofFIG. 5may be performed by tool integration platform240. In some implementations, one or more process blocks ofFIG. 5may be performed by another device or a group of devices separate from or including tool integration platform240, such as client device210.

As shown inFIG. 5, process500may include receiving a message for adaptation (block510). For example, tool integration platform240may receive a message for adaptation.

In some implementations, tool integration platform240may receive the message based on tool220publishing the message. For example, a tool API may encapsulate payload data as a message in RAW format (e.g., a tool specific format), and may provide the message to tool integration platform240in the raw format, such as in a JSON object, XML object, etc., and tool integration platform240may receive the message. In some implementations, a tool API may export the message (e.g., a document identifying multiple defects in a CSV format, a Microsoft Excel file format, or the like). In this case, tool integration platform240may extract each defect message from the document sequentially, concurrently, or the like.

In some implementations, tool integration platform240may receive the message based on lifecycle management platform270publishing the message. In some implementations, tool integration platform240may receive the message based on exposing an interface of tool integration platform240. For example, tool integration platform240may expose the interface of tool integration platform240over a secure connection (e.g., a proxy connection, an HTTPS connection, etc.) to permit tool220to publish a message to a message queue (e.g., an IBM MQ message queue) for adaptation. In some implementations, tool integration platform240may provide a synchronous response to indicate a receipt of the message. As an example, tool220may publish a defect message in RAW format.

As further shown inFIG. 5, process500may include performing message verification based on receiving the message (block520). For example, tool integration platform240may perform message verification based on receiving the message.

In some implementations, tool integration platform240may determine a format of a message. In this case, if tool integration platform240determines the message is already in a canonical data model format and directed to lifecycle management platform270, tool integration platform240may pass the message to lifecycle management platform270without adaptation. Otherwise, if tool integration platform240determines the message is in a canonical data model format but not from an authorized source (e.g., a tool220within tool integration platform240), then tool integration platform240may perform authentication. Otherwise, if tool integration platform240determines the message is in a non-canonical data format, then tool integration platform240may perform authentication.

In some implementations, tool integration platform240may perform verification based on a security policy. For example, tool integration platform240may perform the message verification based on a message source, a message type, a security token included with the message, project details, a message identifier, or the like. In this case, tool integration platform240may log authentication failures, and may automatically transmit a notification to an administrator, to a user, or the like.

In some implementations, tool integration platform240may verify that a defect message is from an authorized source to publish a defect for a particular project. For example, tool integration platform240may verify an Internet Protocol (IP) address as corresponding to the authorized source, a network identifier as corresponding to the authorized source, a user name and password as corresponding to the authorized source, or the like.

As further shown inFIG. 5, process500may include performing message adaptation using a stored adaptation for a tool associated with the message based on performing message verification (block530). For example, tool integration platform240may perform message adaptation using a stored adaptation for tool220associated with the message based on performing message verification.

In some implementations, tool integration platform240may obtain the adaptation tool from an archive of adaptation tools. In some implementations, tool integration platform240may transform the message using an adaptation tool. In this case, when the message is directed to lifecycle management platform270, tool integration platform240may transform the message to canonical data format. Otherwise, when the message is directed to tool220, tool integration platform240may transform the message to a RAW format of tool220. As an example, tool integration platform240may determine whether a defect message is in a RAW format or a CDM format, if the defect message is in a CDM format whether the defect message is trusted or untrusted, and based on the determinations (e.g., that the defect message is in the RAW format, is untrusted in the CDM format, etc.) may utilize a stored adaptation tool to transform a defect message in a raw format to a canonical data format for lifecycle management platform270.

As further shown inFIG. 5, process500may include outputting the adapted message based on performing adaptation (block540). For example, tool integration platform240may output the adapted message based on performing the adaptation.

In some implementations, tool integration platform240may output the message using an API (e.g., an API of lifecycle management platform270to output the message to lifecycle management platform270, an API of tool220to output the message to tool220, etc.) In this case, systems may be subscribed to an adaptation tool, and may receive the message as a result of the message being converted. For example, a portion of lifecycle management platform270that manages defects may subscribe to adaptation tools for integrating defect management tools to receive a message relating to defects when a defect management tool publishes a message.

As a particular example, tool integration platform240may provide a defect to lifecycle management platform270for storage, processing, or the like. In this case, tool integration platform240may send a success message back to tool220to indicate success in providing the adapted message to the lifecycle management platform270. Subsequently, lifecycle management platform270may process the defect message, resolve the defect using functionalities of the lifecycle management platform270, and provide a message to tool220indicating resolution.

Implementations described herein provide tool integration platform240that provides automatic adaptation of data formats for lifecycle management platform270and other tools220that are to integrate into lifecycle management platform270. In this way, tool integration platform240reduces the time to integrate each tool220, thereby improving management of projects, which reduces computing usage by reducing errors, time to resolve errors, effort spent to develop/manage a project, and so forth, relative to a manual integration approach. Also, as a result, tools220need not be cohosted with tool integration platform240because tool integration platform240adapts messages from tools220to a format that lifecycle management platform270can use.