The Software and Systems Engineering Experts​
The Software and Systems Engineering Experts​
SmarterProcess logo

Contacts

SmarterProcess / ReqPro

ul. Antoniego Pajdaka 5/98
03-134 Warsaw, Poland
NIP : 8921405210
Regon : 146293701

About Products

About us

Ink drawing: a consultant beside a client engineer at two monitors, with a control unit on a test bench behind them
Sketch: a completed checklist with an acceptance seal and a key on a server module

Handed over, ready to run · your team keeps the know-how

Widgets

Extending IBM Engineering with widgets and OSLC

What DXL did for DOORS, widgets and OSLC do for DOORS Next: custom functions built around your process.

Overview

New features for IBM Engineering, built with widgets and OSLC

We build custom widgets for IBM DOORS Next and OSLC integrations for IBM Engineering. We also rebuild the DXL scripts your team used in IBM DOORS.

IBM Engineering does not run DXL. You extend it with widgets, small JavaScript and HTML applications that run inside the tool, and with OSLC (Open Services for Lifecycle Collaboration), the REST interfaces that connect data across tools.

A widget sits where your users already work: in the DOORS Next side panel next to a module, or on a dashboard. It reads the artifacts the user selects, works with their attributes and links, and writes changes back through the RM API, as the signed-in user and with the permissions that user already has in the project.

OSLC covers the work between tools. An integration reads and links requirements, test cases and work items across DOORS Next, Test Management and Workflow Management, or connects IBM Engineering to tools from other vendors, so nobody copies data by hand.

Most projects start from something your team already has: a DXL script from DOORS 9, a manual spreadsheet step or a weekly report. We agree what it should do in DOORS Next, build it, and hand over the source code.

What do you need?

Three reasons teams extend IBM Engineering

Bring back your DXL features

Scripts your team relied on in IBM DOORS.

  • Attribute values your DXL used to calculate
  • Menu scripts the team used every day
  • Few developers who can still maintain DXL
Usually a widget with the RM API

Add a feature DOORS Next lacks

Work your team still does by hand.

  • Repetitive edits to links and attributes in a module
  • Checks you run by hand before every review
Usually a custom widget

Connect tools without copies

Data moved between tools by hand.

  • Exports and spreadsheets between tools
  • A separate connection for every other vendor’s tool
  • Artifacts copied instead of linked
Usually an OSLC integration

Choose the technology

RM API, OSLC or both

We pick the technology with you in the first conversation. The table shows what decides it.

CriterionRM APIPlatform API of DOORS NextOSLCOpen standard, RESTRM API and OSLCBoth together
Works in the DOORS Next user interfaceYes: YesPartly: Fewer actionsYes: Yes
Data it reachesPartly: Some: comments, reviews, usersYes: All data exposed by OSLCYes: Full
Configuration awareNo: NoYes: YesYes: Yes
Effort to buildYes: Lowest, well documentedPartly: Higher: OSLC calls and parsingNo: Highest
Choose it whenThe feature works on the module open on screenYou need data from other projects, tools or configurationsYou need both: the screen and the full data

Systems we connect to IBM Engineering through OSLC

JiraPolarionCodebeamerPLM systemsMBSE toolsMATLAB/SimulinkTest toolsYour own systems

From DXL to DOORS Next

What happens to each kind of DXL script

Each kind of script gets a replacement that fits how DOORS Next works. Your list of scripts is enough to start.

In IBM DOORS (DXL)ExamplebecomesIn DOORS Next
DXL attributeobj."Risk" = obj."Severity" * obj."Prob"A widget calculates the value and writes it to the attribute, after a preview
Layout DXLdisplayRich(obj."Status" "")An attribute filled by the widget, shown as a column in a view
Trigger (before save or on open)trigger("check", project, module, pre, save)DOORS Next has no triggers. We agree the replacement with you
Menu script (Tools menu)addMenu("Tools", "Risk", "risk.dxl")A widget in the side panel, one click away
Bulk edits and cleanupfor o in m do { o."Text" = … }A widget with a preview, run in a change set
Export to Word or ExceloleCreateAutoObject("Word.Application")A Publishing templateReport development

How a project runs

From your idea to a working extension

Talk to an engineer
  1. 01

    Tell us what you need

    You give
    The feature, the DXL script or the systems to connect.
    You get
    An approach: RM API, OSLC or both
  2. 02

    Build and test

    You give
    Access to a test server and sample data.
    You get
    A working widget or integration on your test server
  3. 03

    Hand over

    You give
    Your administrators for one session.
    You get
    The extension in production, and administrators who know how to run it
  4. 04

    Keep it working

    You give
    A note before you upgrade ELM.
    You get
    A check after ELM updates and iFixes, under platform maintenance

What you get

What stays with your team

Two developers review a DOORS Next module with a widget panel next to its JavaScript code
Beyond DXL: more developers on the market can support JavaScript.
  • The extension, in production

    Your users open it in DOORS Next like any other widget.

  • Source code you keep

    JavaScript and HTML your developers can read and change.

  • Installation notes

    Where the files live and which server settings the extension needs.

  • A workshop, if you want one

    Your developers learn to build and change widgets.

FAQ

Questions we hear before an extension project

Can you migrate our DXL scripts to DOORS Next?

Not line by line. We rebuild what each script did with a widget, the platform API or OSLC; the table From DXL to DOORS Next shows the usual replacement. For common DXL features there are ready widgets in SmarterWidgets 2.0.

What is a widget in IBM Engineering?

A small application that runs inside the platform, based on Google OpenSocial gadgets and built with JavaScript and HTML.

What is OSLC?

Open Services for Lifecycle Collaboration is a set of specifications that simplify the integration of tools across the lifecycle. The OSLC community that defines it is part of OASIS Open.

Should our extension use the RM API or OSLC?

It depends on whether the feature works on the module open on screen or needs data from other tools and configurations. The comparison in RM API, OSLC or both shows the differences, and we confirm the choice with you before we build.

Will our widgets keep working after an ELM upgrade or iFix?

Usually yes, because widgets use the public interfaces of the platform. Some updates change server security settings, and a widget may then stop loading until your administrator allows its address again. Tell us before you upgrade and we check your extensions afterwards, as part of platform maintenance.

Where do the widget files live, and what must our administrator allow?

The widget files (XML, JavaScript and HTML) sit on a web server your users can reach, often the ELM server itself. Your administrator adds that address to the trusted locations in the Jazz server settings. The installation notes we hand over list each setting.

Can widgets run in Test Management and Workflow Management too?

Yes. Widgets can be added to dashboards in every IBM Engineering application. The RM API works only in DOORS Next, so in Test Management and Workflow Management a widget reads and writes data through OSLC or the application's REST services.

Talk to our consultants

Leave your details and we will get back to you, usually within one business day.

    We will only use your details to respond to your inquiry. Privacy policy