Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Integration Profile Configuration

The following outlines the settings for Microsoft Dynamics Purchase Orders integration .ini file profiles.

Default initialisation filename: 

  • Int_DynamicsOrders_Default.ini

Settings

Key

Description/Setting

IntegrationType

Description: 

Specifies the type of integration to be performed. This is a fixed value that should not be changed.

Setting: 

Dynamics Orders

UseWizard

Description: 

Specifies whether Integration will be run manually or automatically.

Setting: 

0: integration will be run based on the values in the .ini file and can be run automatically without user intervention.

1: Integration will be run using a wizard allowing users to modify the details of the integration.

YieldMilliSeconds

Description: 

Length of time to pause the program in milliseconds.

Setting: 

0 (default)

Databases

Key

Description/Setting

ODBCDSN_Framework

Description:

ODBC DSN name for the Framework database.

Setting: 

FworkSQLEcm

ODBCConnect_Framework

Description:

ODBC DSN connection string for the Framework database.

Setting: 

None

ODBCDSN_FrameworkLicense

Description:

ODBC DSN name for the Framework Licence database.

Setting:

FworkSQLLic

ODBCDSN_Destination

Description:

ODBC DSN name for the Dynamics database.

Setting: 

FworkDynamics

DatabaseName_Destination

Description:

Dynamics database name.

Setting: 

DynaFramInterface

ODBCConnect_Destination

Description:

ODBC DSN connection string for the Dynamics database.

Setting: 

None

Mail Configuration

Key

Description/Setting

Mail_System

Description:

Email delivery method.

Setting: 

0: no email will be sent.

1: email will be sent using MAPI.

2 (default): email will be sent using SMTP.

Mapi_Profile

Description:

Microsoft Outlook user profile name.

Setting:

(default): Outlook

Mail_From

Description:

The name or email address of who/where the email is being sent from.

Setting:

FrameworkIntegration

Mail_Recipient

Description:

These are the mail recipients of integration logs. Multiple addresses can be added if separated with a semi-colon (;). Spaces are not necessary before or after the semi-colon.

Setting:

enterRecipientEmail@yourDomain.com.au;integrationsupport@insulagroup.com.au

Mail_Subject

Description:

Email subject heading.

Setting:

"Framework Integration : Dynamics Orders"

SMTP_Server

Description:

If using Mail_System 2 (SMTP), add the SMTP Server name.

Setting:

enterSMTPServerName (replace this text with your SMTP Server name)

SMTP_UseSecurity

Description:

Is security used for the STMP server?

Setting:

0 (default): A username or password is not required.

1: A username and password is required. If this setting is used, the SMTP_UserName and SMTP_Pwd fields must have a valid username and password.

SMTP_UserName

Description:

A valid username for the SMTP server.

Setting:

enterUserName (replace this text with a valid SMTP Server User Name)

SMTP_PWD

Description:

A valid password for the SMTP username.

Setting:

enterPassword (replace this text with a valid SMTP Server Password)

Criteria

Key

Description/Setting

CriteriaMethod

Description:

Determines which data for Dynamics Ordering is updated.

Setting:

1: Cost Centres.

2: Supplier Entities.

4: Orders.

5: All.

OrderCriteria

Description:

Criteria for selecting which jobs are updated.

Setting:

1: All jobs.

2: Jobs for a specified construction manager.

3: Jobs for a specified supervisor.

4: A single job based on the job number specified.

OrderCriteriaID

Description:

ID for the construction manager, supervisor, or single job as indicated by the OrderCriteria (above).

Setting:

0 (default)

Context

Description:

The Region Division ID if you only want to process Integration for a certain context.

Setting:

0 (default): All region divisions will be processed.

OnlyIntegrateNew

Description:

Instructs Integration to only process job orders that have dates within the range specified below.

Setting:

True: Only records within the date range will be included.

False: All records will be included.

StartIntegrationDate

Description:

If OnlyIntegrateNew is True (above), then we retrieve Databuild orders with dates >= to the StartIntegrationDate.

If StartIntegrationDate is None, then Integration continues as if OnlyIntegrateNew was set to False.

Setting:

None

dd/mm/yyyy

EndIntegrationDate

Description:

If OnlyIntegrateNew is True (above), then we retrieve Databuild orders with dates <= EndIntegrationDate.

If EndIntegrationDate is None, then today's date will be used.

Setting:

None

dd/mm/yyyy

Actions

Key

Description/Setting

LinkPOsToLogisticsItems

Description:

  1. Unlinks cancelled Orders from uncalled Construction Logistics Activities.
  2. Links valid Orders to Construction Logistics Activities based on criteria.

Setting:

True: Link function is switched on

False: Link function switched off

Integrated Fields

The integration of Microsoft Dynamics Purchase Orders to Framework is fixed in the content that is exchanged between the systems. There are no user-configurable integrated fields available to this type of integration.

Database Models

The following database model(s) displays the manner in which data is integrated between the third party application and Framework Integration.

Integration Process

The following information is a low level account of the integration process including criteria, decisions, and outcomes. This information is technical in nature and is provided "as-is" for a detailed analysis of the integration process for system administrators.

  1. Read profile keys to determine which actions to process.
  2. Process Cost Centres
    1. Read all eligible records from Framework table int_cCentreGrp where
      1. Int_cCentreGrp.l_link_sys_gl_id = -2124 (Dynamics)
      2. Int_cCentreGrp.l_int_cCentreGrp_id <> 0
    2. For each record get matching Dynamics record in table DynCostCentreGroupwhere
      1. DynCostCentreGroup. groupID= int_cCentreGrp.s_link_cCentreGrp
    3. Update the int_cCentreGrp.s_link_name field
    4. Read all eligible records from Framework table int_cCentre where
      1. Int_cCentre.l_link_sys_gl_id = -2124 (Dynamics)
      2. Int_cCentre.l_int_cCentre_id <> 0
      3. Int_cCentre.l_int_cCentreGrp_id <> 0
    5. For each record make sure the int_cCentreGrp linked record exists, and if so get the matching dynamics record in table dynCostCentre where
      1. dynCostCentre.costCentreID = int_cCentre.s_link_cCentre
      2. dynCostCentre.ccGroupID = int_cCentreGrp.s_link_cCentreGrp
  3. Process Entities
    1. Get the Framework Db Identifier preference for each context, if a context does not have a setting use the default value for that context.
    2. Read all eligible records from Framework table int_entityGrp where
      1. Int_entityGrp.l_link_sys_gl_id = -2124 (Dynamics)
      2. Int_entityGrp.l_int_entityGrp_id <> 0
    3. For each int_entityGrp record get the matching Dynamics record from dynSupplierGrp where
      1. dynSupplierGrp.groupId = int_entityGrp. s_link_entityGroup and update the group name
    4. Read all eligible records from Framework table int_entity where
      1. Int_entity.l_link_sys_gl_id = -2124 (Dynamics)
      2. Int_entity.l_int_entity_id <> 0
    5. For each record get matching Dynamics record in table dynSupplier where
      1. dynSupplier.supplierId = int_entity.s_link_entity
      2. dynSupplier.contextId = int_entity.l_context_id
      3. dynSupplier.sourceDatabase = value for FW Db Identifier for that context, update the int_entity.s_link_name, int_entity.f_nonCompliance and int_entity.f_preventAlloc fields.
    6. Get matching int_entityGrp.l_int_EntityGrp_id record where dynSupplier.groupId = int_entityGrp.s_link_entityGrp, update the int_entity record with the correct group link.
    7. Update the linked entity's name, abn and acn, update that entities address details, add or update that entities bh, fax, mobile or email details.
  4. Process Orders
    1. Get the Framework Db Identifier preference for each context, if a context does not have a setting use the default value for that context.
    2. Get eligible Framework jobs from v_sched_dbJobOrders where
      1. Job.s_link_boq <> ‘N/A’
      2. Job.l_job_id <> 0
      3. If profile key ‘Context’ is not 0 then add criteria
      4. Job.l_context_id = ‘Context’ (profile key)
      5. and apply order criteria where OrderCriteria is
      6. 2 – Construction Manager • Cst.l_mgr_e_id = ‘OrderCriteriaID’
      7. 3 – Supervsor • Cst.l_super_e_id = ‘OrderCriteriaID’
      8. 4 – Single Job • job.s_job_num = ‘OrderCriteriaID’
    3. For each job get orders and items from Dynamics where
      1. dynPurchOrder.projId = job.s_job_num
      2. dynPurchOrder.sourceDatabase = Fw Db Identifier for this jobs context.
      3. dynSupplier.sourceDatabase = Fw Db Identifier for this jobs context
      4. dynSupplier.contextId = job.l_context_id
      5. If profile key OnlyIntegrateNew is true, add additional criteria where
      6. dynPurchOrder.dateOrdered >= ‘StartIntegrationDate’ – 7 days
      7. dynPurchOrder. dateOrdered <= ‘EndIntegrationDate’ or now if endIntegrationDate is none.
    4. Once we have the Dynamics Order, see if it exists in po_order table where
      1. Po_order.s_jobNo = job.s_job_num
      2. Po_order.s_link_boq = dynPurchOrder.orderId
    5. And we check each Dynamics Order Item, by seeing if it exists in po_item table where • Po_item.s_link_item = dynPurchOrderItem.orderItemId
    6. Orders and items are updated or added. At the end of integration items are checked to see if there are any that need to be removed from Framework.

Needs to be in Construction Stage.

When doing the integration, the program looks at job.l_rpt_index2 it gets the number entered in that field and it checks the ini profile for the key OfficeContext(x)=y where x is equal to the value in job.l_rpt_index2. If it finds this key then it puts the value of y into the contextID. If it does not find an officeContext setting for that value then it uses job.l_context_id and copies this value into the contextID fields. So if you change a jobs context identification, it will only change the contextID field if the ini profile has a key for that OfficeContext. I hope you understand it? Here's an example Job #1 has a job.l_context_id of 1, but a job.l_rpt_index2 of 270 If the ini profile has the key OfficeContext(270)=4 then when integration runs, it will set the FramProj.contextID for Job #1 to be 4. If it does not have the OfficeContext key then the FramProj.contextID will be set to the job.l_context_id value of 1. If you then change the context identifier for Job #1 to be (269) then rerun integration, if there is a key called OfficeContext(269)=2 then the FramProj.contextID will change to 2. If the OfficeContext key does not exist then the FramProj.contextId will change to 1. This is because the key couldn't be found so it uses the value in the job.l_context_id field instead.


  • No labels