Autodesk Constructware® Data Exchange

Transcription

Publication Record
Date
Comments
02/29/08
Reformatted and revised with information from test pages
03/31/08
Added Special Atrributes section containing Parent Child Attributes.
04/09/08
Added Project Wizard Copy Options information to Special Attributes section.
05/06/08
Added Data Exchange for company and address information for Add and Edit
(Updated 4.1.5 Contact Node section and added 4.4.9 Contacts section.)
06/26/08
Added Data Exchange for company contact information for Add and Edit, Rating
Expiration Date on company data, and company label field on additional
addresses.
© 2010 Autodesk, Inc. All Rights Reserved. Except as otherwise permitted by Autodesk, Inc., this publication, or parts thereof,
may not be reproduced in any form, by any method, for any purpose.
Certain materials included in this publication are reprinted with the permission of the copyright holder.
Trademarks
The following are registered trademarks or trademarks of Autodesk, Inc., in the USA and other countries: 3DEC (design/logo),
3December, 3December.com, 3ds Max, ActiveShapes, Actrix, ADI, Alias, Alias (swirl design/logo), AliasStudio, Alias|Wavefront
(design/logo), ATC, AUGI, AutoCAD, AutoCAD Learning Assistance, AutoCAD LT, AutoCAD Simulator, AutoCAD SQL Extension,
AutoCAD SQL Interface, Autodesk, Autodesk Envision, Autodesk Insight, Autodesk Intent, Autodesk Inventor, Autodesk Map,
Autodesk MapGuide, Autodesk Streamline, AutoLISP, AutoSnap, AutoSketch, AutoTrack, Backdraft, Built with ObjectARX
(logo), Burn, Buzzsaw, CAiCE, Can You Imagine, Character Studio, Cinestream, Civil 3D, Cleaner, Cleaner Central, ClearScale,
Colour Warper, Combustion, Communication Specification, Constructware, Content Explorer, Create>what's>Next>
(design/logo), Dancing Baby (image), DesignCenter, Design Doctor, Designer's Toolkit, DesignKids, DesignProf, DesignServer,
DesignStudio, Design|Studio (design/logo), Design Your World, Design Your World (design/logo), DWF, DWG, DWG (logo),
DWG TrueConvert, DWG TrueView, DXF, EditDV, Education by Design, Exposure, Extending the Design Team, FBX, Filmbox,
FMDesktop, Freewheel, GDX Driver, Gmax, Heads-up Design, Heidi, HOOPS, HumanIK, i-drop, iMOUT, Incinerator, IntroDV,
Inventor, Inventor LT, Kaydara, Kaydara (design/logo), LocationLogic, Lustre, Maya, Mechanical Desktop, MotionBuilder,
Mudbox, NavisWorks, ObjectARX, ObjectDBX, Open Reality, Opticore, Opticore Opus, PolarSnap, PortfolioWall, Powered with
Autodesk Technology, Productstream, ProjectPoint, ProMaterials, Reactor, RealDWG, Real-time Roto, Recognize, Render
Queue, Reveal, Revit, Showcase, ShowMotion, SketchBook, SteeringWheels, StudioTools, Topobase, Toxik, ViewCube, Visual,
Visual Bridge, Visual Construction, Visual Drainage, Visual Hydro, Visual Landscape, Visual Roads, Visual Survey, Visual
Syllabus, Visual Toolbox, Visual Tugboat, Visual LISP, Voice Reality, Volo, Wiretap, and WiretapCentral
The following are registered trademarks or trademarks of Autodesk Canada Co. in the USA and/or Canada and other
countries: Backburner, Discreet, Fire, Flame, Flint, Frost, Inferno, Multi-Master Editing, River, Smoke, Sparks, Stone, and Wire
All other brand names, product names or trademarks belong to their respective holders.
Disclaimer
THIS PUBLICATION AND THE INFORMATION CONTAINED HEREIN IS MADE AVAILABLE BY AUTODESK, INC. "AS IS." AUTODESK,
INC. DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE REGARDING THESE MATERIALS.
Published by:
Autodesk, Inc.
111 Mclnnis Parkway
San Rafael, CA 94903, USA
2
Contents
1 About This Guide ............................................................................................ 5
1.1 Who Should Use This Guide? ...................................................................................... 5
1.2 Where do I Get Support .............................................................................................. 5
2 Preparing the Data Exchange .......................................................................... 5
2.1 Overview of Data Exchange ........................................................................................ 5
2.1.1 Inbound Example ........................................................................................................ 6
2.1.2 Outbound Example ..................................................................................................... 7
2.1.3 Why does Constructware use the term exchange instead of integration? ................ 7
2.2 Defining the Data Exchange Setup Process ................................................................. 7
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
Process Overview ........................................................................................................ 7
Roles ............................................................................................................................ 8
Phase 1: Define the Data Exchange Scope .................................................................. 8
Data Mapping .............................................................................................................. 9
Phase 3: Configure Constructware............................................................................ 12
Phases 4-7: Write, Test, and Deploy the Code .......................................................... 13
2.3 Setting Up Constructware to Test Data Exchange .................................................... 13
2.3.1 Step 1: Activate Data Exchange in Constructware .................................................... 13
2.3.2 Step 2: Create User for Data Exchange Process ........................................................ 13
2.3.3 Step 3: Grant Data Exchange Permission to Users.................................................... 14
2.3.4 Step 4: Create a Project to Test the Data Exchange Process .................................... 15
2.3.5 Step 5: Activate the Global Exchange for Data Exchange ......................................... 17
2.3.6 Step 6: Activate the Project(s) and Specific Modules to be Exchanged for Data
Exchange ......................................................................................................................... 18
3 Testing the Data Exchange ............................................................................ 19
3.1 Inbound XML Tests .................................................................................................... 19
3.1.1 Displaying Sample Inbox XML ................................................................................... 19
3.1.2 Testing Inbound XML in Constructware .................................................................... 21
3.1.3 Verifying the Success of the Inbound Test ................................................................ 22
3.2 Outbound XML Tests ................................................................................................. 23
3.2.1
3.2.2
3.2.3
3.2.4
Verifying the Success of Outbound Posts ................................................................. 23
Displaying Sample Outbox XML ................................................................................ 23
Testing Outbound XML in Constructware ................................................................. 24
Retrieving the Working Schema for Middleware Development ............................... 25
4 XML Reference .............................................................................................. 26
4.1 Technical Requirements ............................................................................................ 26
4.1.1 Posting Location ........................................................................................................ 26
4.1.2 Authentication Node ................................................................................................. 26
3
4.1.3
4.1.4
4.1.5
4.1.6
Header Node ............................................................................................................. 27
Doc Node ................................................................................................................... 29
Contact Node ............................................................................................................ 30
DocReference Node .................................................................................................. 35
4.2 Inbox Posting ............................................................................................................. 36
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
Prepare Data ............................................................................................................. 36
Post to Inbox ............................................................................................................. 36
Level 1 Validation ...................................................................................................... 37
Inbox Queue .............................................................................................................. 37
Conversion................................................................................................................. 37
Process XML .............................................................................................................. 38
Check for Acknowledgements................................................................................... 38
Miscellaneous - Special Inbox Posting ...................................................................... 39
4.3 Outbox Requesting .................................................................................................... 40
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
Prepare Data ............................................................................................................. 40
Post Data to Outbox .................................................................................................. 40
Request Data from Outbox ....................................................................................... 43
Process XML .............................................................................................................. 43
Acknowledge ............................................................................................................. 43
Check for Acknowledgements................................................................................... 44
4.4 Miscellaneous Functions ........................................................................................... 44
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.4.8
4.4.9
Method 1: Both Numbers Contained in All Systems................................................. 44
Method 2: Both Numbers Only Contained in Constructware ................................... 44
Special Project Attributes .......................................................................................... 44
User-defined Project Dates ....................................................................................... 48
Custom Fields ............................................................................................................ 49
Date Format .............................................................................................................. 49
Encoding Special Characters ..................................................................................... 49
Companies ................................................................................................................. 49
Contacts..................................................................................................................... 54
4
1 About This Guide
1.1 Who Should Use This Guide?
This guide is intended for the following audiences:

Customers who are considering a Data Exchange. It is especially useful for personnel that will
be directly involved in the exchange, as this document helps clarify the scope of Data
Exchange.

Consultants or other technical resources undertaking to build middleware for Data Exchange.

Site supervisors who are supporting a Data Exchange process.
1.2 Where do I Get Support
If you are a customer, call the Autodesk Constructware support line at 1-800-892-0449. If you are
an Autodesk employee, use the email support mailbox at AEC Application Services.
2 Preparing the Data Exchange
This chapter explains the concepts behind Data Exchange and the steps required before you can
start writing or testing the XML.
2.1 Overview of Data Exchange
The Autodesk Constructware Data Exchange process is a means of moving data between
Constructware and other systems, such as accounting systems, supply chain systems, or vendor
information systems. For example, some customers use Data Exchange to set up projects in
Constructware by transferring data from an ERP system. Other customers establish the budget in
a similar way, and then send all change management data back to the accounting system via Data
Exchange.
Constructware uses XML to exchange data between Constructware and the third-party system.
Data can be sent to Constructware from another system or can be sent from Constructware to
another system. Middleware, which translates the XML into a language each system can
understand, exists between the customer’s side and Constructware’s side (referred to as Inbox
and Outbox).
Once modules to be exchanged are defined during the assessment phase, Constructware provides
the customer with the complete XML schema for each document. This same XML is used to send
data both to and from Constructware. The assessment phase also defines timeframes and triggers
for the customer. The timeframes are used by the customer’s middleware to know when
information should be sent or retrieved. The trigger defines how data is sent from Constructware
to the Outbox.
5
The following is a graphical representation of Autodesk’s methodology and examples.
1. “Collaborative Project Management” in this case represents the Constructware
product. It is available to users via the internet.
2. “ERP System” represents the other system a customer wants to integrate with
Constructware. Its hosting and deployment are independent of Constructware.
3. The “Inbox” represents the Constructware Inbox discussed in this document. This is
where the other system or middleware deposits data, in the form of XML documents,
to be inserted into Constructware.
4. The “Outbox” represents the Constructware Outbox discussed in this document. This
is where Constructware deposits data and acknowledgements, in the form of XML
documents, to be picked up by the other system or middleware.
The concepts of Inbox and Outbox are critical to understanding data exchange with
Constructware.
2.1.1 Inbound Example
For example, budgets are maintained within the accounting system and sent to Constructware.
The data gets from the accounting system to the middleware either by pushing or pulling, as
defined by the customer. The middleware translates the data into the XML provided by
Constructware. The middleware then posts the XML to the Inbox via a URL provided by
Constructware. Constructware validates the XML to ensure the project is active. Once validated,
the XML is translated and inserted into Constructware.
6
2.1.2 Outbound Example
Contracts are maintained within Constructware and sent to the accounting system. The user
enters data into Constructware, where the data is translated to XML and pushed to
Constructware’s Outbox. Each project defines the appropriate trigger to move the data for each
document type from Constructware to the Outbox. The middleware requests data from the
Outbox, using timing defined by the customer. Constructware then answers the request with the
XML of the requested document(s). The middleware translates the XML and inserts that data into
the accounting system.
We’ll follow the budget and contract examples through the rest of this document.
2.1.3 Why does Constructware use the term exchange instead of
integration?
Constructware differentiates between exchange and integration because the two functions are
different. Integration refers to tightly coupled systems, which involves reaching into the opposite
system for data. While this term is generally accepted in the industry, it doesn’t accurately reflect
Constructware’s methodology.
Exchange refers to each system giving information to the other via requests. Neither system has
direct awareness of the other. This arrangement allows for changes like upgrades to be made
independently to either system, while the middleware is updated at the customer’s discretion.
2.2 Defining the Data Exchange Setup Process
Because the need for Data Exchange varies from customer to customer, and the “other” system(s)
differ from customer to customer, the Data Exchange process is designed to be a “black box”—
indifferent to the other system. To achieve each exchange, a prescribed methodology of best
practices is used, typically under the guidance of an Autodesk Consultant.
Best Practice: As illustrated in this guide, thoroughly define and document which data is to be
exchanged before proceeding with any technical work.
2.2.1 Process Overview
The process for Data Exchange begins with an evaluation of the business problem to be solved,
and agreement as to the scope to be accomplished. This scope may be as limited as sending one
type of document to Constructware, or it could be a multifaceted project involving many types of
documents into and out of Constructware.
The following diagram illustrates the key phases in executing a Data Exchange for Constructware.
Each phase is discussed in the sections that follow.
7
Define Data
Exchange scope
Configure
Constructware
Map data
Test XML
documents
Write
middleware
Write specific
XML documents
Test
middleware
2.2.2 Roles
Successful completion of a Data Exchange project requires that you staff the project with people
who can complete the following critical roles.
Role
Tasks
Project Manager

Overall project management for the project
Business Analyst

Prepares the Scope of Work document

Performs the visual and technical mapping for the
exchanged information in both Constructware and the
other system

Creates user data for the Data Exchange process

Grants permissions in Constructware for all necessary
testing

Creates and manages the internal project plan

Validates the mapping before coding begins

Activates the project and modules in Constructware for
Data Exchange

Codes the middleware to the project specifications
Customer Site Supervisor
Technical Lead and team
2.2.3 Phase 1: Define the Data Exchange Scope
A high-level scope is defined and documented in a Statement of Work to ensure that the project is
well-defined. The Statement of Work includes the following information:

Documents to be exchanged
8

Direction of data

Transaction frequency

Error handling

Persons responsible for each task

Timeline for each task
Best Practice: Upload all documentation required and provided for Data Exchange to the
customer’s site under a “Data Exchange” folder within the File Director module. Be sure the
project under which this documentation is stored is easily identifiable. Often, this documentation
is stored within a project called “Constructware Implementation.” Documents within this folder
include the visual and technical mappings, sample middleware, exchange instructions, and
customer-specific XML, which is generated and posted after Phase 2.
For more information about which modules can be exchanged, see
http://secure.constructware.com/Public/Schema/Schema.asp.
2.2.4 Data Mapping
The purposes of Data Mapping are to ensure that:

All fields in both systems have been accounted for.

The team clearly understands how one system affects the other.
The mapping documents are defined by the parties involved in the Data Exchange. This
collaboration ensures that the information needed by the customer or customer system is
properly identified at the field level, which determines which fields are populated in the XML. The
fields used are reflected both in Constructware and in reports, so they need to be correctly
identified before development begins.
2.2.4.1
Visual Mapping
The Visual Mapping document captures a screenshot of Constructware and a corresponding
screenshot of the other system and maps together the fields to be exchanged. The fields to be
used are then selected and numbered. Arrows visually show how the data flows. The numbers are
used later in the Technical Mapping to assist the technical team in performing the mapping.
Best Practice: Perform the Visual Mapping before you begin the Technical Mapping, because
Visual Mapping is critical to fully understanding the scope.
9
2.2.4.2
Sample Visual Mapping
In the two images, note the arrow labeled as number 4 connecting the Cost Type field on the JD
Edwards window to the Object Code field on the Constructware window. Effective visual mapping
connects these corresponding fields to guide the technical mapping.
2.2.4.3
Technical Mapping
Autodesk simplifies the process of technical mapping by providing an online resource that lists all
the Constructware modules and each field within those modules. You can find this resource at
http://secure.constructware.com/Public/Schema/Schema.asp.
When you access this site, the following window appears:
When you select a doc type and click Submit, Constructware generates a spreadsheet for the
selected doc type. The spreadsheet uses the following format:
10
Note that the first four columns refer to the Constructware fields and the remaining columns refer
to the other system’s fields.
The formal Technical Mapping document is an Excel spreadsheet generated by Autodesk with one
tab for each module. The fields previously identified in the Visual Mapping document are marked
with an “X” in the first column of this spreadsheet, labeled “Exchanged,” which makes the data
easier to sort. This spreadsheet identifies the following information:

Exchanged (identifies the fields being used in the Data Exchange)

Constructware (CW) field in the user interface (system label, not custom label)

Constructware field type

Constructware field (XML attribute name) to be exchanged

Constructware XML Parent (document type)

Direction of data transfer, per field

Custom label
The customer technical team member completes the right portion of the spreadsheet, which
needs to include the following columns regarding the other system:

Field ID or field number

Field name

Table name

Field type
11
2.2.4.4
Sample Technical Mapping
Referring back to the example from visual mapping, note that field number 4 in the spreadsheet
shows Budget Code, along with its XML attribute and other notes, as the Constructware field that
corresponds to the Cost Code field in JD Edwards.
2.2.5 Phase 3: Configure Constructware
Constructware is configurable to meet various customer needs. However, once mapping has been
completed, both parties must verify the configuration and update it as necessary. Any future
changes to either system must be shared with the exchange team to reduce the possibility of
conflicts with the data exchange.
2.2.5.1
Items to Review
Pay special attention to the following items as you configure Constructware:
Item
Description
Lookup values
Values must match exactly, including case and punctuation. A warning
message appears if the Lookup table value in Constructware and the
text value provided in the XML do not match perfectly.
Budget code segments
Budget segments must be perfectly matched to the accounting
system. Otherwise, the values that differ should be documented to be
handled in the middleware. The middleware can concatenate or hard
code values if necessary. A warning message appears if a perfect
match is not found within Constructware.
12
Item
Description
Numbering methods
If you are sending documents into Constructware, the numbering
method must be set to Manual. The middleware will submit a
‘Number’ attribute within the document XML.
Vendor numbers
‘VendorNo’ or ‘AddressVendorNo’ must match exactly to a vendor
number within the Constructware Companies database. A warning
message appears if a perfect match is not found.
2.2.6 Phases 4-7: Write, Test, and Deploy the Code
Once the first three phases are complete, the technical team should have all the information
necessary to begin developing the XML code and the middleware. When the middleware
development is complete, testing can begin. Testing typically includes a unit test performed by the
technical team, followed by user acceptance testing performed by the customer business team.
All parties meet to sign off on the testing and determine a date to deploy the middleware into a
production environment.
Important: The unit test should include a business representative familiar with Constructware,
because verification can require reviewing the results inside the product. If an Autodesk employee
needs to perform this testing, that arrangement must be specified in the Statement of Work.
2.3 Setting Up Constructware to Test Data Exchange
The following steps occur during phase 3 of the definition process.
2.3.1 Step 1: Activate Data Exchange in Constructware
Responsible Party – Autodesk
This activity doesn’t begin until after the field mapping is completed and signed off. This ensures
that the correct modules are activated, and that no data may be exchanged until the scope is
clearly understood. The request to enable the data exchange needs to be entered as a feedback
item on the customer’s Constructware site by the Customer Site Supervisor.
2.3.2 Step 2: Create User for Data Exchange Process
Responsible Party – Customer Site Supervisor
The Customer Site Supervisor creates a dedicated user account for the data exchange process. The
middleware uses this user’s login credentials to post the XML to Constructware. To prevent any
problems in the data exchange process, use this account only in the middleware. To ensure
accountability, do not attempt to share an account between a “human user” and a “machine
user.”
Coordinate any changes to the user name or password of this account with the team building the
middleware to ensure that the data exchange process is not interrupted. If this account becomes
locked or its password changes, data exchange activity will be blocked as a security precaution.
For example, many customers require passwords to be changed every n days. Once the specified
number of days has passed, the Data Exchange will no longer work.
The following table lists sample user information:
13
Company Name
Data Exchange
User Name
User
Password
Password1 (change this once you begin)
The “machine user” account does not need to have any specific permissions assigned to it, which
means you can leave all the permissions set to “None.”
2.3.3 Step 3: Grant Data Exchange Permission to Users
Complete the following steps for each user who needs to activate projects for data exchange. This
task requires that you log in under the Supervisor user account.
1. In Constructware, navigate to Maintenance > User Maintenance > Users.
2. Click the radio button next to the user name and click Permissions.
3. On the Edit User Permission window, click the Maintenance tab.
4. Change the permission for Data Exchange to Administrator.
14
5. To save the permissions, click Save/Close.
2.3.4 Step 4: Create a Project to Test the Data Exchange Process
As you create the project, keep these guidelines in mind:

Identify and use a project number. Use it as the project number within the test project, or
ensure that a requirement is made in the middleware to change the project number from A to
B.

Use a project name that can be quickly identified.

Add the appropriate team members to the project, especially if you have “View all Projects”
permission set to “None.”
Complete the following steps:
1. In Constructware, navigate to Project Information > Projects and click New.
15
2. Click the Set Up Manually radio button and click Next (the orange forward arrow).
16
3. Enter a unique project number and project name and click Finish (the green check).
2.3.5 Step 5: Activate the Global Exchange for Data Exchange
To perform this action, you must have permission to access the Data Exchange Setup module (see
Step 3). This step is required for any projects exchanged into Constructware or that are created
manually as demonstrated in Step 4.
1. Navigate to Maintenance > Exchange Maintenance > Data Exchange Setup and click the
Global Modules tab.
17
2. Based on the direction the data flows in the exchange, click the Inbox or Outbox checkbox. In
some cases, you may click both checkboxes.
Note: Inbox indicates data flow from the other system into Constructware, while Outbox
indicates data flow from Constructware into the other system.
3. Click Save.
2.3.6 Step 6: Activate the Project(s) and Specific Modules to be
Exchanged for Data Exchange
The module(s) you activate depend on the project definition and vary based on the direction of
data flow.
1. Navigate to Maintenance > Exchange Maintenance > Data Exchange Setup and click New.
2. Select the project created in Step 4 or another project you previously created. You can select
multiple projects at once.
3. Click the Inbox or Outbox checkbox for the appropriate modules to be exchanged, which you
previously identified during the mapping.
4. If you click Outbox, select a trigger, which tells Constructware when to send the data to the
Outbox. Most triggers are defined to occur when the Budget Status or Cost Status changes.
For more information about triggers, see “Triggers” on page 41.
5. Click Save/Close.
18
3 Testing the Data Exchange
The following steps describe how to test the Data Exchange process within Constructware. The
Inbox and Outbox test pages act as a proxy for the middleware in the Data Exchange process,
allowing you to code, test, and validate with sample data before coding the actual middleware.
The test pages let you separate middleware issues from XML issues.
3.1 Inbound XML Tests
The inbound XML tests fulfill two purposes:

Verifying the validity of any XML documents you plan to post to Constructware

Verifying the success of the Inbox test
[PLACEHOLDER FOR MATT FLOWCHART]
When a test is successful, you can proceed to the Outbox tab to test that end of the process.
When a test fails the Inbox testing, use the error messages to debug the code until the test
succeeds.
First, use the Data Exchange Inbox Test Page to display default XML samples for each available
Constructware module. Then use the samples as a starting point for your XML code. Use the
schema tool at http://secure.constructware.com/Public/Schema/Schema.asp to find the rest of
the fields for writing the XML.
Once you have written the XML in an XML editor, use this window to test the XML. This simulates
the middleware generation of XML files that post data to the Constructware Inbox. Constructware
writes records into the database, so you should be especially careful to use a test project instead
of a live one, as outlined in “Step 4: Create a Project to Test the Data Exchange Process” on page
15.
Note: For a complete understanding of the testing process, make sure you also read “Outbound
XML Tests” on page 23.
3.1.1 Displaying Sample Inbox XML
1. Log in to the customer’s Constructware site and navigate to Maintenance > Exchange
Maintenance > Test Pages.
19
2. Select a doc type from the list.
3. Select an option for the sample XML and click View. Constructware displays the sample XML in
a new window.
20
4. Copy the sample XML into your XML editor (not Microsoft Word or any other Microsoft Office
product), and make any necessary changes to the XML. The required changes, such as
changing “Authentication” and “ProjectNumber,” appear at the top of the sample XML. If you
don’t see the field you need in the sample, use the schema at
http://secure.constructware.com/Public/Schema/Schema.asp to find the rest of the fields for
writing the XML.
3.1.2 Testing Inbound XML in Constructware
1. On the Data Exchange Inbox Test Page, copy and paste the entire contents of the revised XML
file into the XML to Post into Inbox field.
21
2. To test the XML, click Send XML (near the top of page).
Documents that already exist in Constructware, including a project, are updated; otherwise, a
new document is created.
Constructware displays messages regarding the inbound XML in the Automatic Returned XML
from Inbox field, including messages to indicate that the XML was successfully received. If
Constructware encounters issues with authentication or validation, however, it displays those
errors on the corresponding Data Exchange Outbox Test Page window. For more information,
see “Level 1 Validation” on page 37 and “Level 2 Validation” on page 37.
3. To confirm that the changes (or new documents) were successful, go to the appropriate
module in Constructware to verify that the data exists in the correct field and in the correct
format.
3.1.3 Verifying the Success of the Inbound Test
Once you have executed the Inbox test and received the “Message Received Successfully”
confirmation, go to the Data Exchange Outbox Test Page window and post XML to check for any
errors related to Inbox processing.
1. Click the Outbox tab.
2. On the Data Exchange Outbox Test Page, copy and paste the entire contents of the XML file
into the XML Request to Post to Outbox field.
22
Ensure that the header node of the XML file includes the acknowledgement in the format
Acknowledgement =″1″, as in the following example:
<CWXML TemplateName="Data Exchange - Outbox" TemplateVersion="1.0">
<Header Count="20" DocType="Contract" ProjectNumber="" Acknowledgement="1">
<Authentication LoginCompany="company" Username="user" Password="Password1"/>
</Header>
</CWXML>
Review the returned XML for any errors or warnings. For example, a warning message may
indicate that a lookup value or other value was not found in Constructware, and an error message
may indicate that the project has not been turned on to accept records. For more information
about warnings and error messages, see “Check for Acknowledgements” on page 38.
Tip: You can isolate an error by using a parameter of Count=″1″ along with Acknowledgement=″1″
in your XML. This code flags an individual record, which you can correct and repeat for each
record until all errors are resolved.
3.2 Outbound XML Tests
The outbound XML tests allow you to verify the success of the outbound posts from the
Constructware Data Exchange setup.
[PLACEHOLDER FOR MATT FLOWCHART]
Note: For a complete understanding of the testing process, make sure you also read “Inbound
XML Tests” on page 19.
3.2.1 Verifying the Success of Outbound Posts
This step simulates completing an action, such as sending contract information out of
Constructware to the middleware and then on to the accounting system. This action triggers
something to post to the Outbox. In this case, you should post an outbox request without an
acknowledgement flag, because if you include the acknowledgement in the request,
Constructware acknowledges the data immediately and doesn’t display a message that can help in
the testing. Review the Outbox returned XML to verify that it contains the expected content.
The outbound XML test checks the Outbox to determine whether any warnings or errors were
generated from the data posted to the Outbox. This test simulates the customer’s middleware
generation of the XML file and the posting of the data to Constructware Outbox. The following
steps apply to all modules.
3.2.2 Displaying Sample Outbox XML
1. Log in to the customer’s Constructware site and navigate to Maintenance > Exchange
Maintenance > Test Pages.
2. Click the Outbox tab.
23
3. Select a doc type from the list.
4. Select an option for the sample XML and click View.
Constructware displays the sample XML in a new window.
5. Copy the sample XML into your XML editor (not Microsoft Word or any other Microsoft Office
product), and make any necessary changes to the XML. The required changes, such as
changing “Authentication” and “ProjectNumber,” appear at the top of the sample XML.
3.2.3 Testing Outbound XML in Constructware
1. On the Data Exchange Outbox Test Page, copy and paste the entire contents of the revised
XML file into the XML Request to Post to Outbox field.
24
Do not use the Acknowledgement attribute in this revised XML until later in the testing.
Documents that already exist in Constructware, including a project, are updated; otherwise, a
new document is created.
Constructware displays messages regarding the inbound XML in the Automatic Returned XML
from Outbox field, including messages to indicate that the XML was successfully received. If
Constructware encounters issues with XML syntax, login validation, or data validation,
however, it displays those errors on the corresponding Data Exchange Outbox Test Page
window. For more information, see “Level 1 Validation” on page 43.
3. To confirm that the changes (or new documents) were successful, go to the appropriate
module in Constructware.
4. Once you are satisfied with the XML, send a new request with Acknowledge=″1″. This
parameter clears the contents out of the Outbox. Make sure to specify both a project and a
count.
3.2.3.1
Differences Between the Acknowledge and Acknowledgement
Attributes
The acknowledge attribute tells the system to change the flag, which allows the record to be
picked up again. If this attribute is set to ″1″, then the record is no longer available via the Outbox
as the Outbox deletes the information. For example:
<Header Count="20" DocType="Contract" ProjectNumber="" Acknowledgement="1">
</Header>
</CWXML>
In contrast, the acknowledgement attribute tells the system to return only results from previously
posted XML to the Inbox. If this attribute is set to ″1″, then the system returns documents that
were saved within Constructware and sent to the Outbox. For example:
<Header Count="20" DocType="Contract" ProjectNumber="" Acknowledge="1">
</Header>
</CWXML>
Best Practice: In production, you can use the two attributes together in the same XML.
3.2.4 Retrieving the Working Schema for Middleware
Development
When the testing verifies that your XML works properly, you are ready to use it to build the
middleware. The simplest way to do this is to complete an action in Constructware that sends a
25
record to the Outbox. For example, if you set up a trigger to send a record to the Outbox each
time you save a contract, then you can save a contract in Constructware, go to the Outbox and
find the saved record, and copy the XML.
4 XML Reference
This chapter contains technical details related to the middleware and the XML required for
successful posting to the Inbox and Outbox.
4.1 Technical Requirements
Autodesk does not define the language of the middleware; instead, the customer defines it. Visual
Basic 6.0 and C# have been the most commonly used language to build the middleware. The
middleware functions normally include translating XML, error handling, enforcing business rules,
and data validation.
4.1.1 Posting Location
Data exchange works by posting information via HTTPS to Constructware. The customer controls
when information is posted, but Constructware has a defined location for each customer to post.
Use the following URLs for posting information:
Outbox URL
https://secure.constructware.com/Public/Outbox/Outbox.asp
Inbox URL
https://secure.constructware.com/Public/Inbox/Inbox.asp
Set up a test data exchange project within your site. Once you activate it for Data Exchange, you
can use existing information and structures. For details, see “Setting Up Constructware to Test
Data Exchange” on page 13.
4.1.2 Authentication Node
Every posting to Constructware must contain an Authentication node. This information identifies
and authenticates the customer and user.
4.1.2.1
Authentication Node Attributes
Name
Type
Use
Notes
LoginCompany
String 20
Required
Company name of
data exchange user
Username
String 20
Required
User name of data
exchange user
Password
String 20
Required
Password of data
exchange user
26
4.1.2.2
XML Example for Authentication Node Attributes
Authentication LoginCompany="company" Username="user" Password="Password1" />
4.1.2.3
Suggestions

Create a “Data Exchange” user that will be used for posting data to Constructware. Use a
unique ID to ensure accountability. This ensures that all documents sent to Constructware
have a specific user associated with the document, which distinguishes the document as being
sent via Data Exchange. Always use this user’s information when exchanging data with
Constructware.

Adhere to all password rules within Constructware.

Make the username and password more difficult than the standard login names, but don’t use
special characters, such as <>, which cause problems with XML. For more information, see
“Step 4: Create a Project to Test the Data Exchange Process” on page 15.
4.1.3 Header Node
Every XML posting to Constructware must include a Header node. When you post to the Inbox,
however, the header node has no attributes. The attributes specify the information picked up
from the Outbox and recognize information that was previously picked up. The attributes in the
header node can be used independently or together.
4.1.3.1
Header Node Attributes
Name
Type
Use
Default
Notes
Count
Number
Optional
20
Represents the number of
documents requested from the
Outbox in each batch. When
returned from the Outbox, it
represents the number of
documents remaining in the
Outbox. To return all
documents, set this to "0" or
leave this attribute off the
header completely.
DocType
String 50
Optional
N/A
Limits the documents returned
from Outbox to a specific
module (DocType).
ProjectNumber
String 50
Optional
N/A
When supplied to the Outbox
with a valid value, documents
are returned for the specified
project.
27
4.1.3.2
Name
Type
Use
Default
Notes
Acknowledge
Bit
Optional
N/A
Set this attribute to "1" to
retrieve the Outbox record and
mark it never be to returned
again.
Acknowledgement
Bit
Optional
N/A
When supplied to the Outbox
with a value of "1", results are
returned. Also use this attribute
for retrieving
acknowledgements after
posting documents to the
Inbox.
XML Examples for Header Node Attributes
Example 1: Request 10 purchase order document acknowledgements. Purchase Orders were
previously posted to the Inbox, so we need to know if they were successfully entered into
Constructware.
<Header Count="10" Acknowledgement="1" DocType="PurchaseOrder">
Example 2: Request 20 documents. Documents were saved in the system or documents were
previously posted to the Inbox, so you want to get those records.
<Header Count="20">
Example 3: Request 20 documents and acknowledgement. Once recognized, the documents are
no longer available in the Outbox.
<Header Count="20" Acknowledge=”1”>
Example 4: Request number of documents waiting to be picked up in the Outbox. It sends back
only a new count of documents waiting to be picked up from the Outbox.
<Header Count="0”>
4.1.3.3
Suggestions Regarding Acknowledging Documents and Using
Acknowledgements

Acknowledge documents in the Outbox after they have been successfully entered into your
system. Once the document is acknowledged, it will no longer appear as a document to be
picked up in the Outbox. Once the “flag” is changed per the acknowledged record, the only
way to get the document back into the Outbox is to save it again. You cannot make a request
to the application for a specific document’s information.

Request acknowledgements from the Outbox after posting documents into the Inbox. The
acknowledgements will return warning messages, error messages, and confirmation
messages. Typically, two processes run simultaneously at the customer’s site: one for posting
information and one for requesting acknowledgements.
Also see “Differences Between the Acknowledge and Acknowledgement Attributes” on page 25.
28
4.1.4 Doc Node
All documents posted to Constructware or retrieved from Constructware contain a Doc node. The
Doc node contains the attributes specific to the DocType. Each module is its own Doc node, as
noted in the following table:
Module
DocType
Budget
Budget
Budget Code
BudgetCode
Contract
Contract
Contract Change Order
CCO
Contractor Payment Application
ContractorPayApp
Cost Event
CostEvent
Cost Item
CostItem
Invoice
Invoice
Issue
Issue
Owner Change Order
OCO
Payment Application
PayApp
Project
Project
Purchase Order
PurchaseOrder
Purchase Order Change Order
POCO
Request for Change Order
RCO
Request for Quote
RFQ
In the XML, the “Number” is the primary key used to determine whether a document exists within
the specified document type (“DocType”) and the specified project (“ProjectNumber”).
4.1.4.1
Doc Node Attributes
Name
Type
Use
Notes
TransferID
Number
??
Populated automatically by
Constructware. It corresponds to
a record in the Constructware
database and is used for tracking
purposes.
DocType
String 50
Required
DocType typically corresponds to
a module in Constructware.
Available DocTypes are
dependent on the customer. See
the list in this section for details.
29
Name
Type
Use
Notes
ProjectNumber
String 50
Required unless Identifies the project associated
DocType is
with the document. If the project
“Project”
number is not unique in
Constructware, the document is
placed in the first project found
with the same number. To return
items from all available projects,
omit this attribute.
ClientTransferID
String 50
Optional
Used by customer to further
identify the document, it is
typically a unique field in the
other system.
4.1.5 Contact Node
The Contact node allows you to import contacts for various contact fields in the system. Examples
of information that can be assigned to contact fields includes Purchased by, Created by, and
Project Team Members.
Following is an example of the XML for Contact Node attributes
<Doc DocType=”PurchaseOrder” PurchasedBy=”John Doe”…>
<Contact ContactType="PurchasedBy" FirstName="John" LastName="Doe" CompanyVendorNo="401951"
CompanyName="Autodesk" AddressVendorNo="401951" Address1="3780 Mansell Road" Address2="Suite 200"
City="Alpharetta" State="GA" Zip="30022" Phone="770-555-1212" Fax="770-555-2323"
Email="[email protected]"/>
</Doc>
4.1.5.1
Contact Node Attributes (Export)
Constructware writes out a Contact node, per contact, specified in the Doc node. This information
is found in the Contacts module (under Maintenance) in Constructware. When a contact node is
sent into Constructware via Data Exchange, Constructware looks up the contact on the team
member list or the company on the assigned company list.
Name
Type
ContactType
String 50
FirstName
String 30
LastName
String 30
Full Name
String 100
CompanyVendorNo
String 20
30
4.1.5.2
CompanyName
String 200
AddressVendorNo
String 20
ContactAddressLineOne
String 75
ContactAddressLineTwo
String 75
ContactAddressCity
String 30
ContactAddressState
String 20
ContactAddressZip
String 10
ContactAddressCounty
String 50
ContactAddressCountry
String 50
CompanyAddress1
String 50
CompanyAddress2
String 50
CompanyCity
String 30
CompanyState
String 20
CompanyZip
String 10
CompanyCounty
String 50
CompanyCountry
String 50
Contact Node Attributes (Framework Document Import)
Note: Constructware adds the contact or company only if it does not already reside in the
database. It does not edit the contact or company information. Data Exchange cannot edit existing
contact or company information that resides in Constructware.
Constructware uses the following logic when you import a Contact node on a framework
document:
1. Look for the contact by name (First + Last, just First, or just Last, whatever you provide) in the
given project you are importing to.
2. If no contact or multiple contacts are found with that name, then check for the
“CompanyVendorNo”.
3. If there is a “CompanyVendorNo”, find the matching company and select the most recent
contact created for that company, or create one if that company has no contacts.
4. If no “CompanyVendorNo” is provided or no company or multiple companies are found with
the “CompanyVendorNo”, check for an “AddressVendorNo”.
5. If there is an “AddressVendorNo”, find the matching company and select the most recent
contact created for that company or create one if that company has no contacts.
Name
Type
Use
Notes
ContactType
String 50
Required
Corresponds to the contact
type attribute defined in the
31
Doc node
4.1.5.3
FirstName
String 30
Optional
First name of the contact
LastName
String 30
Optional
Last name of the contact
Full Name
String 100
Optional
Full name of the contact
CompanyVendorNo
String 20
Optional
(required if the
company vendor
number already
resides in the
company’s
information)
Company vendor number;
typically the unique company
identifier in accounting
systems
AddressVendorNo
String 20
Optional
Address vendor number;
address identifier in
accounting systems
Contact Node Attributes (Project Import)
Name
Type
Use
Notes
ContactType
String 50
Required
“Team Member”
FirstName
String 30
Optional
First name of the contact
LastName
String 30
Optional
Last name of the contact
CompanyVendorNo
String 20
Optional
(required if the
company vendor
number already
resides in the
company’s
information)
Company vendor number;
identifier in accounting
systems
CompanyName
String 200
Required
Contacts can only exist within
the context of a company
AddressVendorNo
String 20
Optional
Address vendor number;
address identifier in
accounting systems
ContactAddressLineOne
String 75
Optional
Address line one for the
contact
ContactAddressLineTwo
String 75
Optional
Address line two for the
contact
ContactAddressCity
String 30
Optional
City of the contact
32
ContactAddressState
String 20
Optional
State of the contact
ContactAddressZip
String 10
Optional
ZIP Code of the contact
ContactAddressCounty
String 50
Optional
County of the contact
ContactAddressCountry
String 50
Optional
Country of the contact
CompanyAddress1
String 50
Optional
Address line one for the
company
CompanyAddress2
String 50
Optional
Address line two for the
company
CompanyCity
String 30
Optional
City of the company
CompanyState
String 20
Optional
State of the company
CompanyZip
String 10
Optional
ZIP Code of the company
CompanyCounty
String 50
Optional
County of the company
CompanyCountry
String 50
Optional
Country of the company
33
Vendor Number Algorithm
Constructware captures vendor information and uses a matching algorithm to assist in selecting
contacts and companies on specific documents, such as purchase orders. This algorithm is used
only if VendorNumber information is provided.
REM -- If CompanyVendorNo is supplied, then Constructware uses this check, regardless of other info sent:
IF CompanyVendorNo <> NULL THEN
REM – First compare to companies on assigned company list for the project
IF CompanyVendorNo = CompanyVendorNo of Assigned Company THEN
Company on document = Assigned Company
Contact on document = First Team Member of Assigned Company
ELSE IF CompanyVendorNo = CompanyVendorNo of Company for Division specified THEN
Add company as assigned company
Add top contact for the company to Team Members
Contact on document = Team Member of Assigned Company
REM – No company was found, nor did Constructware have a company name to add new
ELSE
Raise Error: Company Name not provided and VendorNo not valid
END IF
END IF
EXIT
REM --If CompanyVendorNo is blank, Constructware next looks to the CompanyAddressVendorNo
IF CompanyAddressVendorNo <> NULL THEN
REM – First compare to companies on assigned company list for the project
IF CompanyAddressVendorNo = CompanyAddressVendorNo of Assigned Company THEN
Contact on document = Top Team Member of Assigned Company
Address on document = CompanyAddressVendorNo address of company
ELSE IF CompanyAddressVendorNo = CompanyAddressVendorNo of Company for
Division specified THEN
Add company as assigned company
Add top contact for the company to Team Members
Contact on document = Team Member of Assigned Company
Address on document = CompanyAddressVendorNo address of company
REM – No company was found, nor did Constructware have a company name to add new
ELSE
Raise Error: Company Name not provided and AddressVendorNo not valid
END IF
END IF
EXIT
34
4.1.6 DocReference Node
Constructware references documents together via DocReferences, especially within Cost
Management. Cost items can exist outside of a parent document, such as a purchase order.
Therefore, you define the link between the cost item and its parent purchase order using a
DocReference.
DocReference Node Attributes
4.1.6.1
Name
Type
Use
Notes
ReferenceType
String 1
Required
Used for referencing documents
together
ReferenceTypeName
String 20
Required
together
DocNumber
String 50
Required
together
DocType
String 50
Required
together
DocDescription
String 255
Required
together
4.1.6.2
Reference Types and Names
Type
Name
Notes
I
Item
Denotes an item (cost item) to another document. This
information appears on the items tab. Example: Cost Item has an
Item reference to the parent PO.
M
Markup
Denotes a special item (cost item) to another document. This
information appears on the Markups tab.
P
Parent
Denotes a parent document to an item (cost item). Example: PO
has a parent reference to the item CI.
C
Child
[DEFINE]
A
Associated
Denotes an associated document, typically an associated contract
or PO. This is used to indicate the projected contract/PO and is
used to pre-select the contract/PO during processing into the
change order.
4.1.6.3
XML Example for DocReference Node Attributes
<Doc DocType="CostItem" …>
35
<DocReference ReferenceType="P" ReferenceTypeName="Parent" DocNumber="00001" DocType="PurchaseOrder"
DocDescription="Sample PO"/>
</Doc>
4.2 Inbox Posting
The process of posting data to Constructware’s Inbox contains several steps. The following is a
graphical representation, with details for each item in the sections that follow. Referring back to
the Inbox and Outbox tests in Constructware, Level 1 validation corresponds to the Inbox tab,
while Level 2 validation corresponds to the Outbox tab.
Middleware
Posting Data to the Constructware Inbox
Check for
Acknowledgements
Post Data to
Inbox
Constructware
Prepare Data
Inbox Queue
Conversion
Level 2
Validation
Level 1
Validation
Return XML
Process XML
Error to
Outbox
4.2.1 Prepare Data
The customer’s middleware application contains data from the other system. This information
could be sent from the other system into the middleware. The information is then converted into
the predefined XML schema. Setting the XML attribute equal to the value from the other system
typically accomplishes this.
4.2.2 Post to Inbox
Information is posted to Constructware via the posting URL defined in “Posting Location” on page
26. To proceed, the customer must activate data exchange for the specific module(s) for each
project.
Refer to the field mapping spreadsheet or schema, which contains a tab for each module utilized
for Data Exchange. The DocType name is the name of the tab and available attributes for the
DocType are listed in the tab.
Cost Items are child items of Cost Management DocTypes, such as PurchaseOrder. These can be
posted with DocReferences to the purchase order or can be posted as child items to the purchase
order. For more information, see “DocReference Node” on page 35.
4.2.2.1
Example XML – Posting Purchase Order “#01” for Project Number
“123”
<CWXML>
<Header>
<Authentication LoginCompany="Company" Username="User" Password="Password1"/>
36
</Header>
<Doc DocType="PurchaseOrder" ProjectNumber="123" Number="01" Description="Test Contract" …>
</Doc>
</CWXML>
4.2.3 Level 1 Validation
Level 1 validation occurs at the initial posting of XML to the Inbox and performs the following
actions:

Authenticates the user

Verifies that the customer has data exchange activated for the module
If level 1 validation fails, then return XML is automatically returned. If level 1 validation passes, the
XML is posted to the Constructware Inbox queue.
4.2.3.1
Example for Error – Level 1 Validation Failed
<CWXML><Header><Error Number="1005" Description="User could not be authenticated"/> </Header></CWXML>
4.2.3.2
Example for Successful – Level 1 Validation Passed
<CWXML><Header><Information Number="1007" Description="Message successfully received."/></Header></CWXML>
4.2.4 Inbox Queue
Constructware’s Inbox queue processes the requests in the order they were posted (FIFO
method). This allows Constructware to control the throughput into the application, if needed. The
average time for XML to exit the Inbox queue is about one minute.
Level 2 checks for valid XML attributes and occurs within the Inbox queue. It checks for the
following, in this sequence:
1. Required information (such as ProjectNumber attribute if DocType<>″Project″)
2. Activation of the module
3. Formatting of the XML
If level 2 validation fails, an error message is posted to the Outbox and the XML is not processed. If
level 2 validation passes, then the XML is converted and then entered into the Constructware
application.
Each XML record has a corresponding Outbox acknowledgement, which can be an error message,
warning message, or confirmation. For details, see “Check for Acknowledgements” below.
4.2.6 Conversion
Constructware must convert the text values, such as budget code or lookup values, into IDs, such
as BudgetCodeID or LookupID, which are used as foreign keys within Constructware’s tables. For
37
more information about the conversion of vendor numbers, see “Vendor Number Algorithm” on
page 34.
4.2.7 Process XML
After conversion, the XML is then inserted and/or updated in the Constructware application. If the
conversion failed, a warning message is posted to the Outbox. If the conversion passed, a
confirmation message is posted to the Outbox. The messages are for final confirmation to let you
know what was posted into Constructware.
Each XML record has a corresponding Outbox acknowledgement, which can be an error message,
warning message, or confirmation. For details, see “Check for Acknowledgements” below.
4.2.8 Check for Acknowledgements
Once the information has been inserted and/or updated in Constructware, the customer requests
the acknowledgements from the Outbox. This allows the customer to retrieve any warnings or
errors that occurred during the validation and/or processing.
Tip: To avoid timing out, set up requests to run every 15-30 minutes.
Three types of acknowledgements exist with Data Exchange:

Warnings

Errors

Confirmations
4.2.8.1
Warnings
Warnings are posted if Constructware encountered an error during conversion of text values into
IDs. The document was inserted and/or updated in Constructware, but the warning message
allows the customer to see problems with a specific field.
4.2.8.1.1 Example – Purchase Order #2 for Project 123 Had the Status Misspelled
<CWXML>
<Header Count="0">
< Doc TransferID="366577" DocType="PurchaseOrder" Number="002"/>
</Header>
<Doc DocType="PurchaseOrder" ProjectNumber="123" Description="Sample PO” TransferID="366577" Number="02">
<Warning Number="1013" Description="Cost Status value ‘Incorrect Status’ for 'CostStatus' could not be found."
ClientTransferID="123456" DocType="PurchaseOrder" DocNumber="02"/>
</Doc>
</CWXML>
4.2.8.2
Errors
Errors are posted if Constructware encountered a fatal error during the validation check or during
the processing. If an error occurred, the document was not entered into Constructware.
4.2.8.2.1 Example
<CWXML>
38
<Header Count="0">
<Doc TransferID="370600" DocType="PurchaseOrder" Number="002"/>
</Header>
<Doc DocType="PurchaseOrder" ProjectNumber=”123” Description="POs not activated" TransferID="370599"
Number="002>
<Error Number="1012" Description="You do not have the service permission required to create this record."/>
</Doc>
</CWXML>
4.2.8.3
Confirmations
Confirmations are posted after each unique document is inserted/updated in Constructware.
4.2.8.3.1 Example – Purchase Order #002 for Project 123 Posted Correctly
<CWXML>
<Header Count="0">
<Doc TransferID="370606" DocType="PurchaseOrder" Number="002"/>
</Header>
<Doc DocType="PurchaseOrder" ProjectNumber="123" Description="Correct PO" TransferID="370606" Number="002">
</Doc>
</CWXML>
4.2.9 Miscellaneous - Special Inbox Posting
Constructware enables a few special Inbox posting abilities, such as selecting a budget cost code
and ledger template via data exchange.
4.2.9.1
Budget
A budget must have a selected Cost Code Template and Ledger Template before budget codes can
be entered, either manually or via data exchange. The templates determine the number of
segments within a budget code and the separators. You can select the templates via data
exchange, which can be sent in immediately after selecting the budget templates.
4.2.9.1.1 Example
<CWXML><Header><Authentication …/>
</Header>
<Doc DocType="Budget" ProjectNumber="123" Description="Test Budget" LedgerTemplateName="Standard"
CostCodeTemplateName="Standard">
</Doc>
</CWXML>
4.2.9.2
Budget Codes
The Budget Code structure is defined by the selected Cost Code Template and must be submitted
in its entirety. The Budget Code is assembled by the system via concatenating the CCSegment
values contained in the CCSegment nodes.
39
Note: All segments that are flagged as “Display in Code” must be included in the XML; otherwise a
warning message is generated.
4.2.9.2.1 Example
<CWXML>
<Header>
<Authentication …/>
</Header>
<Doc DocType="BudgetCode" ProjectNumber="ABC" …>
<CCSegment Name="Cost Code" Value="111111" Order="1" />
<CCSegement Name=”Division” Value=”06” Order=”2”/>
</Doc>
</CWXML>
4.3 Outbox Requesting
The process of requesting information from Constructware’s Outbox contains several steps, but
the primary functions are to get exported data out of Constructware and to provide
acknowledgements. The following is a graphical representation, with details for each item in the
sections that follow.
Note: You can refer back to the Inbox and Outbox tests in Constructware (beginning on page 26),
where Level 1 validation corresponds to the Inbox tab, while Process XML corresponds to the
Outbox tab.
Constructware
Middleware
Requesting Data from the Constructware Outbox
Request
Data from
Outbox
Level 1
Validation
Process XML
Acknowledge
Return XML
Prepare Data
Post Data to
Outbox
Check for
Acknowledgements
4.3.1 Prepare Data
Information is entered into Constructware according to the policies and procedures guide.
4.3.2 Post Data to Outbox
Information is posted from Constructware to the Outbox via the setup defined within the Data
Exchange Setup module. Data in the Outbox has been converted from IDs into text and into the
predefined XML schema provided by Constructware. Only attributes that contain data will be
posted to the Outbox.
40
4.3.2.1
Triggers
Triggers are defined for each module activated for data exchange and define when the data is
posted to the Outbox. These triggers were defined during the field mapping and process mapping,
but they can be changed at any time. The available triggers per module are listed in the following
table.
Module
Available Triggers
Budget
Every Save
Push of Button (with confirmation)
Budget Code
Contract
Every Save
When Cost Status equals [selected value]
Contract Change Order
Every Save
Cost Event
Every Save
When Budget Status equals [selected value]
Cost Item
Every Save
Invoice
Every Save
Owner Change Order
Every Save
Purchase Order
Every Save
41
Module
Available Triggers
Purchase Order Change Order
Every Save
Request for Change Order
Every Save
Request for Quote
Every Save
When Status equals [selected value]
4.3.2.1.1 Every Save
Used if transactional information is needed in the other system. Every save of the record
(creation, pushing the Save button, routing with status changes, processing, etc.) will write XML to
the Outbox. This option isn’t typically used since most systems don’t need or want to know about
the information, especially cost information, until it has been approved.
4.3.2.1.2 Push of Button
The user initiates the sending of XML to the Outbox via the “Send XML” button available on the
toolbar for the module. The user must have permission to change the record in order to send the
record to the Outbox. On push of the button, the system displays a pop-up window to ensure the
user knows the information is about to be sent to the other system. You can revise the message
displayed to the user through the Data Exchange Setup module.
For example, generate all budget codes with estimated dollars, and then send all codes to the
other system in bulk. The user would enter multiple budget codes, select all codes within the
multi-edit page, and then send the XML.
4.3.2.1.3 When Status Equals
The document is converted to XML and written to the Outbox when the document reaches a
certain status. One or multiple statuses can trigger the information to be converted and this
option works in conjunction with the approval routing available in Constructware. This option is
the most popular, because it allows the most flexibility and it aligns with standard business
processes.
The options for budget status triggers are Approved, Cancelled, New, Other, Pending Approval,
Projected, and Uncommitted. The options for cost status are Approved, Approved Change,
Cancelled, New, Other, Pending Approval, Projected, and Uncommitted.
For example, the routing is defined to change the status to “Pending Approval” at the beginning of
the route and to “Approved” at the end of the route. If the trigger is defined as when the status
equals “Pending Approval” and/or “Approved”, then at the beginning and end of the route the
document will be written to the Outbox.
42
4.3.3 Request Data from Outbox
The customer’s middleware application sends a request to Constructware’s Outbox via the posting
URL defined in “Posting Location” on page 26. The customer must have data exchange activated in
order to proceed. This will request any documents that have been previously saved within
Constructware and written to the Outbox. Only attributes that contain data will be posted to the
Outbox.
Refer to the field mapping spreadsheet supplied (or “Exchange Task Plan”), which contains a tab
per module activated. The DocType name is the name of the tab and available attributes for the
DocType are listed in the tab.
Cost Items are child items of Cost Management DocTypes, such as PurchaseOrder. These will be
written out as DocReference nodes to the Purchase Order.
4.3.3.1
Examples
Example 1: Request 10 purchase order documents.
<Header Count="10" DocType="PurchaseOrder">
Example 2: Request 20 (default) documents. Documents were saved in the system or documents
were previously posted to the Inbox, so you want to get those records.
<Header Count="20">
Level 1 validation occurs at the initial posting of XML to Outbox. It authenticates the user and
verifies that the customer has data exchange activated for the module. If level 1 validation fails,
then return XML is automatically posted back. If level 1 validation passes, the request is posted to
the Outbox.
4.3.4.1
Example for Error – level 1 Validation Failed
<CWXML>
<Header>
<Error Number="1005" Description="User could not be authenticated"/>
</Header>
</CWXML>
4.3.5 Process XML
The customer’s middleware application converts the data in the XML schema and then posts that
information into the other system.
4.3.6 Acknowledge
Documents in the Outbox need to be acknowledged after they have been successfully entered
into your system. Once a document has been acknowledged, it is no longer available in the
Outbox. Documents can be acknowledged at the same time as they are requested from the
Outbox.
43
4.3.6.1
Example
Acknowledge the documents that have been processed successfully. A unique TransferID, which
can be used to acknowledge specific document, is included in every Outbox record. Once the
TransferID has been acknowledged, it is no longer available in the Outbox.
<Header TransferID=”12345” Acknowledge=”1”>
4.3.7 Check for Acknowledgements
Once the information has been processed in the middleware, the customer requests the
acknowledgements from the Outbox. This allows the customer to retrieve any warnings or errors
based on content that occurred during validation or processing.
4.4 Miscellaneous Functions
Constructware understands that information in other systems, such as accounting systems, has a
different numbering method than Constructware. The OtherReferenceNo attribute, available in all
document types, is designed specifically for the purpose of tracking the unique document number
found within your accounting system. The OtherReferenceNo is also the secondary key used to
determine whether a document exists within the specific document type and the specified
project. It is used only if the value supplied in the “Number” field cannot be found or if no
“Number” field is supplied.
For example, if you send XML that includes both number fields, Constructware first looks to find
the document based on the Number field. If it cannot find the document based on the Number
field but the document contains a value for OtherReferenceNo, Constructware updates all the
number fields with the new number, including the Constructware Number field.
This field can be used in two different methods.
4.4.1 Method 1: Both Numbers Contained in All Systems
This method requires an update to the customer system to store Constructware’s unique number.
Constructware updates its system with your unique number, which is entered in the
OtherReferenceNo attribute. After both systems have both numbers, Constructware looks up the
existing document based on the Number attribute and the customer system looks up the
document based on the OtherReferenceNo.
4.4.2 Method 2: Both Numbers Only Contained in Constructware
This method requires no update to your system to store Constructware’s unique number, because
the OtherReferenceNo has been added as a secondary key. Constructware updates its system with
your unique number, which is entered in the OtherReferenceNo attribute. Constructware then
attempts to find an existing document based first on the Number attribute, if provided, and then
by the OtherReferenceNo attribute.
4.4.3 Special Project Attributes
This section contains information about special project attributes.
44
4.4.3.1
Parent Child Attributes
You can use Data Exchange to set the parent project and related numbering attributes for a
project. Each parent project must have a unique project number because Constructware looks up
parent projects by the project number. This mimics the functionality in the product, as follows:
The following table lists the attributes you use in Data Exchange to import the data:
Field Name in Constructware
Attribute
Parent Project
ParentProjectName
N/A
ParentProjectNumber
Use parent numbering for Documents
DocumentsUseParentNumbering
Use parent numbering for Cost Management items
CostManagementUseParentNumbering
Show Documents in parent log
DocumentsShowInParentLog
Show Cost Management items in parent log
CostManagementShowInParentLog
The following rules determine when the attributes can and cannot be set in Data Exchange:
Attribute
ParentProjectName
ParentProjectNumber
Rule
 Used only for Data Exchange outbound. Will be ignored
for inbound transactions.
 Inbound
 Outbound
 Use only for new projects. A valid parent project cannot be
45



DocumentsUseParentNumbering




CostManagementUseParentNumberin
g
DocumentsShowInParentLog
CostManagementShowInParentLog












set during an edit. This can be accomplished using the user
interface, where business rules are enforced.
Must exist for any of the following four options to be valid.
If more than one active project is found with this project
number, no data is added and an error message is put in
the outbox.
If the parent project number is not found at all, data is
inserted (basic project data, but none of the 4 options
below are inserted) and a warning is put in the outbox.
Inbound.
Use only for new projects; not valid for edits.
When selected, you must select
DocumentsShowInParentLog or Data Exchange will
automatically set it and send a warning.
Used in conjunction with ParentProjectNumber (a
ParentProjectNumber must exist to use this.)
Inbound.
When selected, you must select
CostManagementShowInParentLog or Data Exchange will
automatically set it and send a warning.
Used in conjunction with ParentProjectNumber.
Inbound.
You can select this option without setting
“DocumentsUseParentNumbering”
Inbound.
Can be selected without setting
CostManagementUseParentNumbering.
See “Parent – Child Relationships” in the Constructware help for more information.
4.4.3.2
Project Copy Options
When importing a project, you can select the options that are available for the project. The copy
options appear in Constructware in the “Sections to Copy” portion of the second page of the
Project Copy Wizard, as follows:
46
If you include a copy option name, that section will be copied. To not copy a specific section, do
not include that copy option at all. For Project CSI Codes, the “Copy From Other Source” option is
not available for Data Exchange. The only option for Data Exchange is to copy from the source
project.
Following is an xml example for an Inbox posting:
<CWXML TemplateName=”Data Exchange – Inbox” TemplateVersion=”1.0”>
<Header>
<Header>
<Authentication LoginCompany=”Company” Username=”username” Password=’password”/>
</Header>
<Doc DocType=”Project” Number=”DX-001” Name=”Data Exchange Test 1” Description=”My Description for project 01”>
<CopyOptions SourceProjectNumber=”DX-PAR” NotifyOnCopyComplete=”1”>
<CopyOption Name=”ProjectDetails” IncludePrimaryPhoneAndFax=”1”/>
</CopyOptions>
</Doc >
</CWXML>
Note: See the Public/Schema/SchemaHelp.asp page for the exact names to use.
47
4.4.4 User-defined Project Dates
Constructware can exchange user-defined project dates, within the project XML, via a ProjectDate
node per unique date. This information is found on the Dates tab within Project Details. The
values of the date fields and the fields shown (Estimate Complete, Actual Complete, etc.), are
defined in the Project Dates lookup table within Lookup Maintenance. Hiding information on the
Dates tab does not prevent the data from being sent via data exchange.
Note: Values (Name) must exist in Constructware or a warning message will be posted and data
not brought into the system. A ProjectDate node must be sent in per unique
ProjectDateType/Date combination.
4.4.4.1
4.4.4.2
Attributes
Name
Type
Use
Notes
ProjectDateType
Predefined values:
Required
Corresponds to the date column
name above the table. Values
are defined by Constructware.

EstimatedComplete

ActualComplete

EstimatedStart

ActualStart
Name
String 50
Required
Name of the user-defined date
as specific in the lookup tables
Date
Date
Required
Date entered for the userdefined date specified in the
lookup tables
Example
<CWXML>
<Header>
<Authentication LoginCompany="clientcompanyname" Username="user" Password="Password1"/>
</Header>
<Doc DocType="Project" ProjectNumber="HQC70406" Number="HQC70406" Name="HQC70406- REMOVE RETILE
FLOORS" AddressLineOne="BLDG ROOM" AddressLineTwo="10 CRC B-3 LAB" ActualStartDate=”1/1/2007”
ActualCompletionDate=”12/31/2010” EstimatedStartDate ="12/1/2006" EstimatedCompletionDate ="11/1/2010"/>
<ProjectDate ProjectDateType="EstimatedStart" Name="Entry Date" Date="1/24/2007"/>
<ProjectDate ProjectDateType="ActualStart" Name="Review Date" Date="1/24/2007"/>
<ProjectDate ProjectDateType="EstimatedComplete" Name="2. Study: RFCA" Date="1/1/2003"/>
</Doc>
</CWXML>
48
4.4.5 Custom Fields
Constructware can exchange custom fields within any of the Constructware modules via a <Field
Type="Custom"> node per field. To find the custom fields and their values in Constructware,
navigate to Maintenance > Data Maintenance > Module Customization and select a module to
edit. Then click the Attributes tab and note fields with a Type of Custom.
For more information about working with custom fields, see the online help in Constructware. In
particular, navigate in the help to Data Maintenance > Module Customization > Module
Customization Procedures > Attributes tab > Custom Fields, or just search for “Custom Fields.”
4.4.5.1
Example
<CWXML>
<Header>
<Authentication LoginCompany="companyname" Username="user" Password="Password1"/>
</Header>
<Doc DocType="Project" ProjectNumber="HQC70406" Number="HQC70406" Name="HQC70406- REMOVE RETILE
FLOORS" EstimatedStartDate ="12/1/2006" EstimatedCompletionDate ="11/1/2010"/>
<ProjectDate ProjectDateType="EstimatedStart" Name="Entry Date" Date="1/24/2007"/>
<Field Type="Custom" Name="Custom Field Label" Value="Value To Import">
<Field Type="Custom" Name=" Discrete Service CAN" Value="Value To Import">
</Doc>
</CWXML>
4.4.6 Date Format
You can use Constructware to specify how a date is entered and displayed per user within the
application. However, dates sent via Data Exchange will always be sent in the format
MM/DD/YYYY. This information could be displayed in the product differently per user, depending
on each user’s settings.
4.4.7 Encoding Special Characters
Per standard XML rules, certain characters must be encoded to be pass as valid XML. The
following table provides a brief list of these characters and their ASCII equivalents.
Character
ASCII Equivalent
&
&amp
<
&#60
>
&#62
4.4.8 Companies
You can exchange inbound and outbound company information for the Add and Edit actions to
avoid duplicate data entry across systems. CompanyName andCompanyVendorNo are required
49
fields for new companies. If a CompanyName is not included, nothing is imported and the
following message displays: “No Company Name provided.” For edits to existing companies, only
the CompanyVendorNo is required to look up the company.
The system checks for duplicate companies by name and only displays the following warning if
one is found: “A duplicate company may exist.” Note that when a duplicate company exists, the
system still imports the data. You can find more detailed information about CompanyVendorNo
and AddressVendorNo later in this section.
4.4.8.1
Example
Following is an XML example of a company with a primary address (this address information is
added as attributes of the Doc node) and two secondary addresses (secondary addresses are
added as child elements of the Doc node):
<CWXML>
<Header>
<Authentication LoginCompany="company" Username="user" Password="password"/>
</Header>
<Doc DocType="Company" CompanyRecordState="A" CompanyName="Exchange Company"
CompanyType="General Contractor" CompanyVendorNo="ABC123" CompanyNo="001" PrimaryCSICode="" Division=""
CompanyEmail="" WebSite="" CompanyNotes="" BusinessType="" OfficialName="" PrincipalLocation="" FederalID=""
RatingNotes="" MinProjectValue="" MaxProjectValue="" OverallRating="" FinancialRating="" AddressLineOne=""
AddressLineTwo="" City="" State="" Zip="" County="" Country="" AddressVendorNo="" TaxRate="" TaxExemptNo=""
Phone="" Fax="" TollFree="" RatingExpirationDate=”1/01/2009” >
<Address AddressVendorNo="DEF456" Description="Second Address" AddressLineOne="" AddressLineTwo=""
City="" State="" Zip="" County="" Country="" TaxRate="" TaxExemptNo="" Phone="" Fax="" TollFree=""
CompanyLabel=”Exchange Company Inc.”/>
<Address AddressVendorNo="GHI789" Description="Third Address" AddressLineOne="" AddressLineTwo=""
City="" State="" Zip="" County="" Country="" TaxRate="" TaxExemptNo="" Phone="" Fax="" TollFree=""
CompanyLabel=”Exchange Company Inc.”/>
</Doc>
</CWXML>
Important Note: See the XML Schema for specific field information.
Note: All standard Data Exchange rules apply to things like lookup values.
MoneyField Validation
For MinProjectValue and MaxProjectValue, the system verifies that the value provided is numeric
and falls within the valid range (approximately -922,337,203,685,477 to 922,337,203,685,477). If
either condition fails, nothing is written to the company record. Following are the two possible
errors:

Currency value ‘<Imported Value>’ for ‘<FieldName from XML>’ failed validation (not a
valid number).

Currency value ‘<Imported Value>’ for ‘<Field Name from XML>’ failed validation (exceeds
valid range).
Other Numeric Field Validation
50
Validation for TaxRate is similar to the Money fields. However, the valid range is -50,000 to
50,000. The same error messages are used.
Lookup\Division Validation
Validation for the following fields is similar to the other Import fields. If the value is not found,
nothing is written to the record and a warning message is passed to the Outbox:
 Division
 CompanyType
 BusinessType
 OverallRating
 FinancialRating
The two possible warning message are as follows:
 “Lookup value ‘<Imported Value>’ for ‘<Field Name in XML>’ could not be found.”
 “Division value ‘<Imported Value>’ could not be found.”
Primary CSI Code Validation
When a primary CSI code is passed, the system validates that a CSI code matching the code passed
in exists. Then, the CSI code is added to the “Company CSI Code” list and is set on the Company as
the “Primary CSI Code”. The two possible warnings are as follows:

Standard CSI Code value ‘<Imported Value>’ for ‘PrimaryCSICode’ not found.

Standard CSI Code value ‘<Imported Value>’ for “PrimaryCSICode’ returned multiple
matches. The most recent Code was assigned.
CompanyRecordState
If anything other than “V” is passed in, it is treated as an “A” (for Active). If “V” is passed in, it is
first evaluated to determine if the company is allowed to be voided. The two conditions are that
there are no User or Employee accounts still active (or locked or draft in the case of users).
51
Note: Employees are considered “Inactive” if they have a status of “Terminated”. The two error
messages are the same as in the product, as follows:

“This company <Company Name> currently has one or more active, draft, or locked user
accounts, and may not be voided.”

“This Company <Company Name> has one or more Contacts that are Employees. All
Employees must be terminated in Human Resources before the Contacts and Companies
may be voided.”
Additional Note: After voiding a company, all contact records for the company are also voided
and removed from all project teams (set to “Inactive”) and groups. You will no longer be able to
see the voided contacts in the Contact Log (because the company is void).
4.4.8.2
CompanyVendorNo
The Company node includes the primary address attributes. The CompanyVendorNo is the unique
identifier that determines the Add or Edit functionality, and duplicate checks are made against the
CompanyVendorNo field.
CompanyVendorNo Rules
As with the other strings, the CompanyVendorNo is truncated to 20 characters, if necessary.
However, because it is also the primary key to search for which company to Edit, the following
error conditions apply to the CompanyVendorNo:
Scenario
Resulting Action(s)
No address information is supplied when
adding a new company
 A primary address is created.
The XML contains a CompanyVendorNo
that is already in the system
 That Company is edited.
The XML does not contain a
CompanyVendorNo
 An error occurs.
The XML contains a CompanyVendorNo
that does not already exist
 The CompanyVendorNo is added to the database.
No CompanyVendor No is provided.
 “No Vendor Number provided.” message displays.
 The AddressVendorNo is set the same as the
CompanyVendorNo.
 No action takes place.
 Processing stops.
 Nothing is imported.
Multiple entries using the same
CompanyVendor No.
 “Multiple Companies found matching Vendor
Number ‘<Imported Value>’ message displays.
 Processing stops.
 Nothing is imported.
52
Outbound
The Outbound limit is 500 contacts. For companies with more than 500 contacts, the Contact
nodes will not be included with the outbound company XML.
4.4.8.3
AddressVendorNo
The AddressVendorNo is not required for primary, but is required for child nodes. If
AddressVendorNo is not provided for a new company, the CompanyVendorNo is used for the
Primary Address AddressVendorNo. The Primary Address Addresss VendorNo can be changed
during a company Edit by providing an AddressVendorNo. (The system always looks up the
Primary Address with the company, never with the AddressVendorNo.)
Child nodes on the Company node record all other addresses of the company. The unique
identifiers are the AddressVendorNo and the CompanyVendorNo. No templates are applied to any
phone and fax numbers. Duplicate checks are against the AddressVendorNo (in conjuction with
the CompanyVendorNo).
Notes: The Address VendorNo is not required. See the table in “Companies – Basic String Length
Validation” for more information.
Address Sales Tax Error Conditions
The following table contains Sales Tax Error condition scenarios and the resulting actions and
warning messages:
Scenario
Resulting Action
XML contains the TaxRate and
the TaxExemptNo.
 Set the TaxExemptNo.
When Editing an existing
address and providing a
TaxRate, the existing address
already has a Sales Tax
Exempt No.
When Editing an existing
address and providing a
TaxExemptNo, the existing
address already has a Sales
Tax Rate.
 Send a warning about
ignoring the TaxRate.
 Do not set TaxRate.
 Send a warning.
 Set the TaxExemptNo.
 Clear the Sales Tax.
 Send a warning.
Warning Sent to User
Address '<AddressVendorNo>' cannot
have both a Sales Tax Rate and a Tax
Exempt No., the Sales Tax Rate has
been removed.
Address '<AddressVendorNo>'
currently has a Sales Tax Exempt No.,
cannot fill in Sales Tax Rate.
Address '<AddressVendorNo>'
currently has a Sales Tax Rate of
<Current Tax Rate>, this has been
cleared to accommodate the Sales Tax
Exempt No.
You can still set a Tax Rate on an address with an existing Sales Tax Exempt No. by setting the
“TaxExemptNo” to “” (empty string).
53
Additional Address Note Handling
The following tables contain additional Address errors and warnings:
Errors
Scenario
Error Message
Address XML has no “AddressVendorNo”
“No AddressVendorNo provided. Address
creation aborted.”
No “Description” sent when creating creating
New Address.
“Address ‘<Address Vendor No.>’ does not have
a Description. Address creation aborted.”
Warnings:
Scenario
Warning Message
Try to set “Description” when editing Primary
Address.
“You are not allowed to set the Description on
the Primary Address.”
Set the “AddressRecord State” to “V” when
editing Primary Address.
“You are not allowed to Void the Primary
Address.”
Set “Description” to (empty string) when editing “Address ‘<Address Vendor No.>’ does not
Address.
have a Description. Cannot clear the
Description on an existing Address.”
In addition, all string lengths are validated, as well as the Sales Tax / Tax Exempt No. data, the
same as for Companies. The “Description” field is the only new field and it has a length of 50.
4.4.9 Contacts
A contact can be selected on a document via the Contact node; however, Constructware matches
on the VendorNo field to find the company on the team member list. If the company does not
exist on the team member list, a warning message is generated. You can also import contacts by
themselves or as part of a company.
Contact for Team Members on a Project
The Contact/Company can first be added to the team member list via Data Exchange and then
selected on a document. Refer to the XML snippet below:
<CWXML>
<Header>
</Header>
<Doc DocType="Project" ProjectNumber="ABC" Number="ABC" Name="Exchange Project" AddressLineOne="10
Main Street" AddressLineTwo="Suite 100" City="Atlanta" State="GA" Zip="30383" County="Fulton" Country="USA">
<Contact ContactType="TeamMember" FirstName="John" LastName="Doe" CompanyVendorNo="111"
CompanyName="Autodesk, Inc."/>
</Doc>
</CWXML>
54
Importing a Contact by Itself
The following XML example is for a contact that is independent of a project.
<CWXML>
<Header>
</Header>
<Doc DocType="Contact" ContactRecordState="A" OtherRefNo="UVW123" CompanyVendorNo="ABC123"
FirstName="Jane" LastName="Doe" Salutation="Mrs." Title="Senior Project Manager" AddressVendorNo="Add123"
Mailstop="First Floor" Email="[email protected]" Phone="(802) 555-1222" Fax="(802) 555-1222" Cellular="(802)
555-1222" Pager="(802) 555-1222" MiscPhone1="(802) 555-1222" MiscPhone1Desc="Phone 1 description"
MiscPhone2="(802) 555-1222" MiscPhone2Desc="Phone 2 description" MiscPhone3="(802) 555-1222"
MiscPhone3Desc="Phone 3 description" Notes="This is a note">
</Doc>
</CWXML>
Importing a Contact Based on a Parent Company
The following XML example is for contacts that are nodes of a doctype of company.
<CWXML>
<Header>
</Header>
<Doc DocType="Company" CompanyRecordState="A" CompanyName="Exchange Company"
CompanyType="General Contractor" CompanyVendorNo="ABC123" CompanyNo="001" PrimaryCSICode="" Division=""
CompanyEmail="" WebSite="" CompanyNotes="" BusinessType="" OfficialName="" PrincipalLocation="" FederalID=""
RatingNotes="" MinProjectValue="" MaxProjectValue="" OverallRating="" FinancialRating="" AddressLineOne=""
AddressLineTwo="" City="" State="" Zip="" County="" Country="" AddressVendorNo="" TaxRate="" TaxExemptNo=""
Phone="" Fax="" TollFree="" RatingExpirationDate="1/01/2009">
<Address AddressVendorNo="DEF345" AddressRecordState="A" Description="Second Address"
AddressLineOne="345 Broad St." AddressLineTwo="Suite 100" City="New York" State="NY" Zip="" County="" Country=""
TaxRate="" TaxExemptNo="" Phone="" Fax="" TollFree=""/>
<Address AddressVendorNo="GHI678" AddressRecordState="A" Description="Third Address"
AddressLineOne="122 Lucky St." AddressLineTwo="" City="Colchester" State="VT" Zip="05446" County="Chittenden"
Country="" TaxRate="" TaxExemptNo="" Phone="" Fax="" TollFree=""/>
<Doc DocType="Contact" ContactRecordState="A" OtherRefNo="XYZ123" FirstName="John"
LastName="Doe" Salutation="Mr." Title="Senior Project Manager" AddressVendorNo="Add123" Mailstop="First Floor"
Email="[email protected]" Phone="(802) 555-1212" Fax="(802) 555-1212" Cellular="(802) 555-1212" Pager="(802)
555-1212" MiscPhone1="(802) 555-1212" MiscPhone1Desc="Phone 1 description" MiscPhone2="(802) 555-1222"
MiscPhone2Desc="Phone 2 description" MiscPhone3="(802) 555-1222" MiscPhone3Desc="Phone 3 description"
Notes="This is a note"/>
<Doc DocType="Contact" ContactRecordState="A" OtherRefNo="UVW123" FirstName="Jane"
LastName="Doe" Salutation="Mrs." Title="Senior Project Manager" AddressVendorNo="Add123" Mailstop="First Floor"
Email="[email protected]" Phone="(802) 555-1222" Fax="(802) 555-1222" Cellular="(802) 555-1222" Pager="(802)
555-1222" MiscPhone1="(802) 555-1222" MiscPhone1Desc="Phone 1 description" MiscPhone2="(802) 555-1222"
MiscPhone2Desc="Phone 2 description" MiscPhone3="(802) 555-1222" MiscPhone3Desc="Phone 3 description"
Notes="This is a note"/>
</Doc>
</CWXML>
For more information, see “
55
Contact Node” on page 30.
4.4.9.1
Data Exchange for Contacts
You can exchange inbound and outbound contact information to avoid duplicate data entry across
systems. For contacts, the unique identifier is OtherRefNo. If OtherRefNo is not provided, then
the unique identifier is email (in conjunction with CompanyVendorNo).
Contacts Rules

No templates will be applied to any phone and fax type numbers.

The only duplicate checks will be against the OtherRefNo. If OtherRefNo is not provided,
the duplicate check will be against email (in conjunction with the CompanyVendorNo).

If there is no AddressVendorNo, assign the contact to the primary address. If the
AddressVendorNo is not found, assign the contact to the primary address and a warning
displays in the outbox.
Exchangeable Fields
(Fields in User Interface)
Public Names
(Name in XML)
State (record state)
ContactRecordState
Other Ref No
OtherRefNo
Vendor No
CompanyVendorNo (used only to look up the contact, not
editing this value on the company record)
First Name
FirstName
Last Name
LastName
Salutation
Salutation
Title
Title
Address Selection
(from Address Vendor No)
AddressVendorNo
Mailstop
Mailstop
Email
Email
Phone
Phone
Fax
Fax
Cellular
Cellular
Pager
Pager
Misc Phone 1 Description
MiscPhone1Desc
Misc Phone 1
MiscPhone1
MiscPhone2Desc
56
Misc Phone 2
MiscPhone2
MiscPhone3Desc
Misc Phone 3
MiscPhone3
Notes
Notes
Inbound and Outbound Processing
For inbound and outbound by themselves, contacts must be exchangeable in Data Exchange
setup. Outbound as child nodes to the company, only the company needs to be exchangeable in
Data Exchange setup. Inbound as child nodes to the company Data Exchange requires that the
companies and contacts be exchangeable in Data Exchange setup.
Outbound is by Push of a Button─this is a global module for Data Exchange setup (like projects).
When outbound is exchanged as part of a company node, if the company has more than 500
contacts, no contact nodes will be included and a warning will be set in the outbox indicating this
condition.
Additional Contacts Handling
The following table contains additional Contacts errors and warnings:
Errors
Scenario
Resulting Action
No unique identifier is supplied.
That item is not added or updated.
Contact is a user, employee, etc.
All current rules for changing the record states
through the user interface apply.
57

Autodesk Constructware® Data Exchange

Transcription

Similar documents

Mise en page 1

horsing - Le Bocage Normand

Untitled - Content admin

Efficient XML

Autodesk® Autodesk® Constructware® Manage efficiently, deliver

Introducing XAIRA…

Integrated Aircraft Design Network

Overview Benefits of SimEx

Cutting edge design.

jack of all trades, master of none?