Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: C API limitations
Topic Summary:
Created On: 24-Nov-2003 22:49
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Marc Battistello, on Friday, March 11, 2005 4:58 PM

Answer:
Interesting thread and I have been thinking the same thing lately. The single thread limitation of the client drives obvious limitations in a web environment, which is typically not a "single" threaded environment. The API provided carries along the same limitations so I dont think that their is much that can be done at this time.

Ive been lately thinking of building some "wrapper" applications for web purposes that would compensate for the existing limitations. Ive been working with doors for a couple years and the same questions and issues keep coming up so I figure now is as good as time as any to start exploring this.

Im looking at building a set of tools in java that encompass some of the functionality that is not available in the existing Telelogic toolset - web/db access, upload/extract/xml, license management (not really telelogic, but since they use flexlm I consider it included), reporting.

If anyone is interested in collaborating drop me an email Marc
 24-Nov-2003 22:49
User is offline View Users Profile Print this message


Todd Tapper

Posts: 1
Joined: 4-Nov-2003

In the solution that I want to implement, it seems the clever scheme of scripted IPC that's been devised is adding quite a bit of complexity to the design. It would be wonderful if the API could be modified to overcome two limitations: only one IPC channel can be managed by the API library at a time, and there is no direct interface to the actual DOORS server that doesn't go through an intermediate DXL Server.

My company has a web-based application where users browse process management information. Certain data presented is related to information maintained by DOORS. Users would like to be able to easily click a link to see this related information.

The concept is simple; but the devil is in the details. It seems that if I want to support concurrent requests from multiple users, I'm going to have to CreateProcess() two processes for each request handler. One process is the DXL server that actually connects to DOORS, and the other would be the process that provides a callback to receive the text data. The latter process can't maintain more than one IPC channel due to the API library's limitation on this, which is why I will have to start up two processes for each request handler. On top of that, I have to implement another multi-threaded process to kick off these processes and herd the reqests and responses among them.

In my mind this is an incredibly circuitous way of doing things especially since I only want to deal with text data between the web service and DOORS. And a cleaner solution could be coded completely in C/C++ without the need to delve into a scripting language that isn't generally known among members of my development team.

Am I missing something? Is there actually a direct method of interacting with the DOORS server that either isn't documented, or that I missed in existing documentation? Or do my observations seem accurate. What other alternatives to extracting data from DOORS and displaying on our webpages are there?

Edited: 25-Nov-2003 at 02:03 by Todd Tapper
Report this to a Moderator Report this to a Moderator
 2-Dec-2003 00:14
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

Todd,

I'd have to say that you have stated the problem rather well. I know of no way to directly access the DOORS data other than their API.

There are DXL routines that can generate HTML for the data that is in DOORs but I haven't had the pleasure of needing to perform this type of operation. I am very interested in knowing how you plan on moving forward (if at all) with your solution because we very well may have to travel down that path.

Sorry I couldn't be of more assistance. Good luck.
Report this to a Moderator Report this to a Moderator
 8-Jan-2004 17:52
User is offline View Users Profile Print this message


Christian Hansen

Posts: 8
Joined: 8-Jan-2004

Your observations are acurate.

I am also lacking a proper API.

I need to have some libraries that I can compile with my own code to access the DOORS db.

I have written a two way web interface to the DB using the DXL API.

Actually it works quite ok, but it is a bit slow.

It stopped working when I migrated from 6.0SP1 to 7.0. But I still have the code
Report this to a Moderator Report this to a Moderator
 12-Jan-2004 15:30
User is offline View Users Profile Print this message


Graham Stradling

Posts: 67
Joined: 19-Sep-2002

Got to say we've generally gone with the option that Roger mentioned of doing batched readouts of data, the API appears to be rather poor and the API manuals are poor.

-------------------------
Graham Stradling,

Alcatel-Lucent.
Report this to a Moderator Report this to a Moderator
 11-Feb-2005 17:14
User is offline View Users Profile Print this message


Bruce Tuskey

Posts: 77
Joined: 2-Mar-2004

Can you post your code? With the very limited information on the DOORS API, it would be great help.

Thanks in advance!

-------------------------
Bruce Tuskey
Sr. Principle Engineer
Tuskey@gmail.com

"All that is gold does not glitter, not all those who wander are lost:..." - Gandalf the Grey (JRR Tolkien)
Report this to a Moderator Report this to a Moderator
 12-Feb-2005 06:17
User is offline View Users Profile Print this message


Marc Battistello

Posts: 13
Joined: 19-Sep-2002

Answer Answer
Interesting thread and I have been thinking the same thing lately. The single thread limitation of the client drives obvious limitations in a web environment, which is typically not a "single" threaded environment. The API provided carries along the same limitations so I dont think that their is much that can be done at this time.

Ive been lately thinking of building some "wrapper" applications for web purposes that would compensate for the existing limitations. Ive been working with doors for a couple years and the same questions and issues keep coming up so I figure now is as good as time as any to start exploring this.

Im looking at building a set of tools in java that encompass some of the functionality that is not available in the existing Telelogic toolset - web/db access, upload/extract/xml, license management (not really telelogic, but since they use flexlm I consider it included), reporting.

If anyone is interested in collaborating drop me an email Marc

Edited: 12-Feb-2005 at 06:19 by Marc Battistello
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.