Crypt Trials Technology » Great

Oracle To Dynamics Gp Great Plains Integration Notes

admin — Sat, 17 Jul 2010 16:16:52 +0000

If you work for large organization, which has independent subsidiaries and branches, running various ERP and accounting systems: Microsoft Dynamics GP, SAP Business One for example, and in the headquarters you have custom Oracle database application deployed (CRM, Sales Order Processing, EDI, eCommerce web site, Warehouse Management, Quality Control, etc.), then you might be interested in cross platform integration between Dynamics GP and Oracle application. Again, if you have Great Plains Dynamics implemented, it is rather legacy MRP and ERP systems situation, where either Oracle or Great Plains is the legacy, depending on your corporate IT strategy. In this small publication we would like to review Oracle integration options to Great Plains Dynamics GP:

1.       Dynamics GP SDK. We recommend you to review GP eConnect, as the set of libraries for your integration gateway to program bidirectional integration to and from Dynamics GP. You can deploy eConnect in Microsoft Visual Studio .Net C# or VB project, from where you could also call ODBC gateway to Oracle database world. You can either schedule eConnect gateway in batch integration scenario, or call it in real time with parameters of current transaction

2.       Dynamics GP Integration Manager. This scenario is more user friendly , but at the same time less flexible (if you are programmer and seeking for sophisticated custom integration logic). You can also schedule Dynamics GP IM in batch integration mode (look for generic Windows application macro solutions, where you can call EXE application with parameters, or simply purchase IM scheduler from Microsoft Business Solutions Dynamics GP reseller)

3.       Connection to Oracle. Here you may think about several technologies. If you are working for Oracle shop IT department, you should be already familiar with ODBC options at the Oracle end. If you are in Microsoft SQL Server type of circle, consider creating SQL Linked Server (in MS SQL Server 2005 or 2000) to open the door to Oracle databases

4.       Text files as Data interchange, CSV and Tab Delimited. This approach is feasible if your Oracle resides in Unix or upscale Linux (also consider XML data interchange, which is relative to the idea of platform independent text file). Text files, exported from Oracle database should be easy to process either in Dynamics GP Integration Manager or eConnect Add-on. If you have the objective to move your GL transactions from Dynamics GP General Ledger to Oracle Financials, you can easily export new Dynamics GP GL records via SQL view from GL20000 table

ERP Version Upgrade: Microsoft Great Plains Example and General Notes

admin — Sun, 11 Jul 2010 01:22:15 +0000

If you have been using your accounting and MRP application for the long time without investing into version update, now it might be time for you to consider getting updated. Assuming that you represent mid-size enterprise, you should expect that corporate ERP version upgrade is something that you should build the strong action plan for – to avoid your ERP shutdown time and possible rollbacks, if things are not going as expected. Additional considerations should be given to the situation when you have third party or custom-made modules: reports, integrations, EDI, etc. Let’s review what you should expect:

1. ERP annual maintenance plan. Nowadays software industry deploys this practice, when your purchase of MRP system just opens the door to ERP implementation, following support, access to newest versions, etc. Naturally, all these benefits have a cost for software development company and they are typically translated to you in the form of ERP annual enhancement program. Check with your ERP partner that you are current in this plan

2. Cross-platform integrations upgrade. In our opinion, ERP customers spend extra funds in cross platform scenarios, such as when their Sales Order Processing system is hosted in Linux/PHP environment and ERP application is Microsoft SQL Server and Windows based, here you should also recognize that MRP upgrade process requires IT person or programmer, who is comfortable with both platform: UNIX and Microsoft Windows in our example

3. Microsoft Dynamics GP upgrade scenarios. GP customizations, especially legacy ones were typically done in Great Plains Dexterity IDE and sanscript programming language. Reporting tools: FRx, Microsoft SQL Server Reporting Services or SRS, GP ReportWriter (where you modify such popular reports as SOP Blank Invoice Form) and Crystal Reports; eConnect opens the door to Microsoft Visual Studio .Net C# or VB developer to the realm of GP objects: customers, vendors, employees, GL transactions, Sales and Vendor Invoices

4. ERP rollback rescue. Obviously, we are optimists, however we should consider contingency plans, where we roll back to old positions. In the case of corporate ERP version update, rollback may cause substantial business opportunity loss

5. Switching from one ERP to another. When you have been operating on ERP A, it is not easy to switch to ERP B as it typically triggers fullscale data conversion and migration, employee retraining, custom logic reprogramming

Great Plains Support: Web Sessions and Remote Access Technology

admin — Sat, 10 Jul 2010 06:18:22 +0000

Microsoft Dynamics GP ERP could be pretty efficiently supported remotely on the case by case basis and via such technologies as web session, remote desktop connection, VPN. Great Plains is based on Microsoft technologies: .Net, SQL Server, Dexterity, SRS, Sharepoint and all these are hosted in Windows Server platform, where remote support is natural. Let’s review technologies and remote support options:

1.       Application Consulting support, also referred as functional consulting. This is where you need help with GP functionality: entering and posting transactions, such as SOP invoices, POP receipts, GL transactions; master records creation: customer, vendor, employee; modules setup: AR, AP, Inventory, etc. This job could be efficiently done via such web session technologies as gotomeeting, that allow you to create efficient targeted training environment for remote GP functional consultant and your accounting personnel

2.       Great Plains Dexterity Customization support. GP modifications are typically distributed via so-called chunk files and it highly recommended that Dex custom modules be tested in your test company environment – you simply copy your production company into test one and then run Dex alternative logic there. Assuming these scenarios, we recommend you to enable either RDC (remote desktop connection) or VPN to your Server – then Dex developer doesn’t need your IT people to babysit him to do chunk deployment and beta testing and QA phases

3.       Microsoft Dynamics GP Integrations support. Integrating with your legacy systems is very popular programming routine; this scenario may deploy such tools as GP Integration Manager, SQL stored procedures, eConnect applications (written in C#, or VB and deployed via Microsoft Visual Studio). As IM currently relies on such new technologies as eConnect, we recommend you to allow remote integration programmers to install integration tools and test integration via remote desktop connection technologies

4.       EDI or Electronic Document Interchange. There are a lot of articles written on EDI technical aspects, however if you think through them – they are about either exporting in fixed field text format EDI documents or import fixed field text file as Edi source to GP SOP, RM or POP modules. Both routines could be programmed in SQL stored procedure – some challenge here is to find SQL developer, who is familiar with EDI technologies and formats

5.       GP reporting remote support. SRS development and reports design is typically done through MS Visual Studio snap in and considering this we recommend you to allow report designer to have VPN connection or RDC to your server. If you have historical Crystal Reports or prefer reports to be implemented in Crystal Reports, then install Crystal Reports Designer on your server, accessible for CR designer

Great Plains Reseller in Chicago

admin — Fri, 09 Jul 2010 07:33:23 +0000

Microsoft Dynamics GP ERP successfully serves mid-size and large companies as their accounting and for smaller organizations MBS offers Microsoft Small Business Financials. Microsoft Dynamics GP, which is current name of former Great Plains Dynamics is sold and implemented through Value Added Reseller or VAR channel. If are in process of selecting your next ERP application and think that GP is a good fit, you should request presentation from one of the GP resellers in your area or in your industry niche if you are larger organization and need nationwide support. We would like to provide additional highlights to help you in the selection:



1.       GP overview. This ERP system is supported and developed by Microsoft Business Solutions and it has so-called core set of modules as well as numerous vertical and horizontal solutions supported either by MBS or by add-ons developers or GP ISV partners. Great Plains fits you if you are in the majority of industry niches: wholesale and retail, discrete manufacturing, project organization, service firm, consulting business, employment agency to name a few

2.       GP technology. Great Plains is available on Microsoft SQL Server DB platform only since version 8.0, current version is 10.0. GP architecture is often associated with its historical Integrated Development Environment and programming language GP Dexterity. Dex in turn was written in C programming language and it is in essence the shell to resolve computer and DB platform direct dependence

3.       GP modifications. Great Plains is flexible and gives you several customization options: Dexterity, eConnect, SQL stored procedures, SDK. You can also consider publishing GP data through web extensions, written in .Net C# or VB with eConnect SDK

4.       GP Integrations.   Great Plains Integration Manager is the first tool to consider, recent version is reshaped and now has connectors, deploying eConnect methods and under laying encrypted stored procedures

5.       Openness to eCommerce developer. eConnect was initially dedicated to e-commerce programmer to enable GP objects manipulation: Sales Order Processing Invoice, Inventory Item, GL account and transaction

Great Plains Partner Newsflash: Dynamics GP Large Scale Ongoing Integration

admin — Thu, 08 Jul 2010 23:40:55 +0000

Microsoft Dynamics GP or former Great Plains Dynamics and eEnterprise should be a good fit for large organization, where you may need in high volume EDI integration to Great Plains from your Electronic Document Interchange order placement channel. If you have very strong internal IT team with Microsoft Visual Studio .Net C# or VB programmers with good SQL scripting background, you can decide to program integration in Dynamics GP eConnect SDK. In this small publication we are describing bullet proof method of deploying Dynamics GP Integration Manager module:1. Integration Source. In simple ad-hoc integrations you typically work with tab or comma delimited text files. In the case of large volume integration you typically have to deploy more advanced ODBC compliant connection. In Dynamics GP Integration Manager this is Advanced ODBC. Please, follow these steps: create new integration, name it and right click on Sources, add source, select Advanced ODBC and Define New Advanced ODBC, select ODBC Data Source (this is what you have already defined in your computer registry, Oracle Sales for example to get connected to your Oracle Custom Sales Order Processing database and application), in the SQL Statement edit area type in something like this: Select * from SalesOrders. In this case we assume that SalesOrders is either Oracle table or Oracle View. With Advanced ODBC Dynamics GP data source you can do pretty much what SQL is about: union, group by, sum, where, join, you name it. We recommend you to create SQL linked server construction in your Microsoft SQL Server 2005 or 2000, where you create heterogeneous query to Oracle, mySQL, Ingress, DB2 database, and enjoy the flexibility of Microsoft SQL Server Stored Procedure2. Integration Destination. Here for Dynamics GP 10.0 you have two options: Microsoft Dynamics GP and Microsoft Dynamics GP eConnnect. There is the difference between the two. Microsoft Dynamics GP is built upon OLE Server and as such it deploys your Great Plains user workstation to push data into Dynamics GP. As you can imagine OLE server is ancient technology and it is deploying the whole stack of layers to get final call (on Great Plains Dexterity level). eConnect is new and cool thing (based on direct encrypted SQL stored procedures). When you select either one of the destination adapters, then you are in normal realm of Dynamics GP modules: SOP (typically targeted in eCommerce applications), POP, GL, Payroll, etc. Please, be aware that eConnect adapter requires company database name (in comparison to OLE adapter, where company name is taken from your user login context)3. Destination Mapping. Here you can further customize integration logic by applying VBA scripts and translations. Follow this methodic: for the chosen field, change rule to Use Script, then on the left side click on the expansion button to the script value (default No) and in Script Editor demonstrate your VBA scripting skills. For Dynamics GP VBA scripting instructions, please open Great Plains Integration Manager Guide. In IM help -> Index, the using scripts or VBScripts objects. Another good advise: C:Program Files (x86)Microsoft DynamicsIntegration Manager 10helpdocumentation and open IMUserGuide.pdf book. Here you will have a lot of fun on practicing VBA scripts for Dynamics GP objects as well as doing Translation for object names in IM

Great Plains Customization Technologies: Highlights for Software Developer

admin — Sun, 04 Jul 2010 15:55:20 +0000

When Microsoft acquired Great Plains Software and then integrated Great Plains into so-called Microsoft Dynamics ERP products family as Dynamics GP, modification tools became more Microsoft and .Net oriented, as you could expect. However in the initial design in earlier 1990th Great Plains Dynamics was intended as multi platform product and its fundament was built on new technology named Great Plains Dexterity. Considering complicated origin of GP, let’s review development tools:

1.       Dexterity. Great Plains Dexterity, as we already mentioned is the heart of GP design, and it is in turn written as the shell in C programming language to secure certain flexibility, especially the option to switch from one operating system or computer platform to another. Being very powerful and flexible, Dex doesn’t facilitate so-called rapid development scenario as it is not object oriented and it requires you as programmer to have several years of extensive Dexterity programming prior to participation in Dexterity programming project. Dexterity has its own scripting language Sanscript. Latest versions of Dex support such cool Microsoft technologies as COM objects and Web Services, plus you can call SQL Stored procedures from Dex code. To get quick tour into Dexterity architecture, you may install it from GP CD #2 and open Dynamics.dic file – this dictionary has core GP logic and it is written in Dexterity

2.       VBA and Modifier. We were watching closely the competition between various GP customizing tools. And we still think that Modifier should be reviewed prior to eConnect. Modifier is in essence the module, written in Dexterity, which allows you to add buttons and fields to existing screens of GP as well as take them off. To animate new fields you use VBA scripting language, often you use ADO technology to access GP tables from modified forms

3.       eConnect. This SDK opens for you GP objects: master records (customer, vendor, GL Account, employee, prospect) and work transactions (SOP invoice, Purchase Order, Payroll Entry). eConnect is based on encrypted SQL stored procedures, plus it has several layers of technology wrappers – in fact it is friendly for Microsoft Visual Studio C# or VB developer. If you are integrating eCommerce website with your GP back office, we recommend you to consider eConnect as the main integration tool, also consider Autoposting Server to post batches of SOP invoices in GP

4.       SQL Stored Procedures Integrations. If you think eConnect is too heavy and complex and you are comfortable to do light SQL insert statement to populate GP tables, then SQL scripting is an option. However, we discourage newcomers from trying SQL insertion prior to researching other integration tools first

5.       GP Integration. Of course integration is not the same as customization, however we would like to orient you here as well. GP traditionally has Integration Management Module. With current version 10.0 IM has new connectors – from now on you can use eConnect connectors to do integrating

Scm Custom Extensions For Microsoft Dynamics Gp Great Plains

admin — Wed, 30 Jun 2010 00:44:48 +0000

Supply Chain Management often is Barcode driven and includes inventory replenishment, and also Sales order execution with high level of processes automation. If you are mid-size organization, engaged in Warehouse Management, Merchandise Automatic Replenishment, advanced Barcode automated Order Execution (Order Assembly, Picking and Packing, Finished Goods Returns and Disassembly), you may expect certain level of custom programming in implementing Supply Chain Management Solution for Microsoft Dynamics GP. We already described in several publications specifics of Great Plains Warehouse Management, Barcoding, Consignment, integration with Retail Application, Inventory Cycle count. In this paper we will try to give you generic SCM approaches and options, especially when you came to the conclusion, that existing out-of-the-box Dynamics GP SCM packages do not provide required functionality:

1. External Application integration with Dynamics GP versus extending Great Plains screen in Supply Chain Management application. This is probably one of the first questions or topics for your homework. There are great SCM self sufficient systems out there on the Corporate ERP software market and if you think that reasonable integration to Dynamics GP is OK, you can decide to take that route. In Dynamics GP there are several integration tools to consider. In the simplest and probably the most recommended scenario, consider GP Integration Manager module, where you can integrate CSV or tab delimited text files as well as via Advanced ODBC query – whatever could be exposed via ODBC bridge (including cross platform DB queries: Oracle, DBII, PHP/MySQL/Linux, Pervasive SQL). You can also explore Dynamics GP eConnect to move records from SCM system to GP. In the case of eConnect you have more control, including real time transaction integration triggering options (eConnect libraries could be included into your MS Visual Studio C#, VB application, where you program your custom integration)

2. Extending native Dynamics GP Screens and business logic to achieve Supply Chain Management goals. Microsoft Dynamics GP itself has very rich business logic, especially in such modules as Inventory Control (items transfer between the sites, cycle count, cost and price control), Bill of Materials (for light discrete manufacturing, including production on demand or order execution), Purchase Order Processing (especially with Purchasing Configurator – this module might be the core of your SCM Inventory Replenishment), Sales Order Processing (where you can capitalize on order execution steps, including order or invoice line allocation/fulfillment, backorders) – to give you several reasons to consider. You may pose the question for your management team – we already bought Dynamics GP Business Ready licenses, where a lot of our SCM required logic is already included – we just need to enable Barcode automation to make Great Plains friendly for your Warehouse workers. If you decide to take Dynamics GP existing business logic extension route, here are the tools for you to consider: Microsoft Dexterity (this is Great Plains architecture with its own scripting language Sanscript and Integrated Development Environment, you have no limits with Dexterity, except probably the fact that Dex requires experienced programmers, who are preferably familiar with Dynamics GP Source Code). Second tools could be Modifier with VBA – it is not .Net compliant but still does wonderful job or extending Dynamics GP screens with new editable fields, push buttons, etc., where you would need to animate these new objects with VBA scripts. VBA allows you to push data to Dynamics GP tables via ADO technology

3. Barcoding Focus. In Dynamics GP every screen where you have editable fields could be subject for Barcode integration (or where you would like to upload barcode scanner batch). The reason to consider custom add-on programming here is simple – each Corporate ERP application screen has several types of editable fields: Drop Down List, Check Box, Radio Group, Edit Field and plus these fields should be filled in determined sequence. Barcode scanner is capable to fill scanned code into Edit Field, and it requires custom logic to automate the rest of the Screen business logic

4. International SCM focus. Microsoft Dynamics GP is localized in most of English speaking countries: USA, Canada, UK, Australia, New Zealand, Oceania, South Africa, plus it is localized to some extent in Spanish speaking South and Central America and Caribbean basin, It is also available in French in Quebec/Montreal. Dynamics GP is also translated to Arabic. In the countries and regions where GP is not localized: Brazil, China, Russia, Japan, Continental Europe, Korea – we recommend SAP Business One

5. How to get further help? Please call us 1-866-528-0577, 1-630-961-5918 or email us help@albaspectrum.com

Microsoft Great Plains Integration Notes

admin — Sun, 27 Jun 2010 09:50:19 +0000

Microsoft Dynamics GP, current version 10.0, deploys MS SQL Server 2005 or earlier versions. If you are software developer, it is probably first that enlightens you – design custom integration with SQL stored procedures or views. However you should first get the idea on the majority of available programming and integration tools to make the best pick for your customization project. Let’s review GP integration options:

1. GP Integration Manager. IM is intuitive integrating tool, which allows end user to design query, map query fields to GP business objects, such as GL account, SOP Invoice and all the other (except probably some exotic ones, typically related to newly acquired modules, very new functionality, or the like). If you need to alter standard GP integration logic, IM allows you to deploy VBA scripting and program events: before query, before document and others. To give you practical example – in before document event VBA script could alter document date, if you would like to issue your integrated invoices twice a month, while integrating every day. Besides VBA scripting you can deploy field value translation – if your integration query gives you customer ID as 100 and in GP it is AARONFIT001, you can import translation table and apply it in your integration. Translation table can be imported in Excel format

2. eConnect. This tool opens integration door to MS Visual Studio .Net C# or VB programmers and among them are eCommerce developers. eConnect core is set of encrypted SQL stored procedures, which replicate GP Dexterity business logic – this means that eConnect “validates” GP logic and it is a way safer than direct SQL scripting. eConnect covers the majority of GP modules and objects, however it doesn’t cover such modules as Invoicing (however it covers Sales Order Processing or SOP module, which is more powerful one)

3. Microsoft Dexterity, former name is Great Plains Dexterity. This IDE and programming language allows you to go into GP heart and utilize its source codes and engines. The example of Dex customization is Albaspectrum Posting Server, which allows eCommerce eConnect developer to post Sales batches directly from eCommerce application, which is not possible in pure eConnect. Dexterity allows you to create all the thinkable integrations, however it requires Dex programming experience and it is not recommended to count on newcomers in Dex.

4. SQL Scripting. If eConnect is not an option for you (where we would strongly recommend you to review eConnect one more time and change possible your mind in favor of eConnect option), you can go ahead with SQL scripts. Review GP table structure in Tools->Resource Description->Tables, then in GP test environment create the transactions you plan to integrate via GP user interface and analyze the records created in the tables. Try to feed one transaction in test company and then try to run check links: Maintenance->Check Links, select your series and work or master tables in them – be sure check links doesn’t produce error report. SQL stored procedures integration is not self evident and here we just give you initial orientation.

Custom Sales Order System Integration With Great Plains Microsoft Dynamics Gp

admin — Sun, 27 Jun 2010 08:54:28 +0000

If your company is established business, which uses one or another in-house developed Business Management System and you are now in situation when you are moving the business to the new phase, where you need industry strength ERP system behind, or how now they name it accounting backoffice, you may be interested to read on how Microsoft Dynamics GP Great Plains can do the job for you. Of course, and this is not a big secret, GP integration needs to be designed and programmed by GP consultants, who will work in concert with your internal IT professionals. Let’s take a look at typical scenarios:

1. Sales Order Processing and Vendor Drop Shipping. If you have strong presence on the web as eCommerce reseller, there is the chance, that what you actually do is transfer customer sales orders to vendor drop ship purchase orders. If this is the case, you will need to integrate your SOP system with Microsoft Great Plains. The first and the most reliable tool to choose from and consider on the first place is GP Integration Manager. In IM itself, please review eConnect connectors to integrate Sales Order Processing and Purchase Receipt documents. eConnect route is definitely faster, in order to see the difference you should know that traditional IM connector uses Great Plains workstation as OLE server to do the job, basically filling up fields in the form and so, validating business logic

2. Direct eConnect programming. This option should be faster in comparison to Integration Manager way, as IM eConnect connector has to do all the steps in business logic validation, while in eConnect MS Visual Studio.Net c# or VB programming you can choose the steps to perform in business logic validation. However eConnect “atomic” stored procedures might still be less efficient as they had to validate the logic of Microsoft Dexterity

3. SQL Stored Procedures approach. SQL is definitely the fastest tool to try, however you should be proficient in SQL scripting and understand the impact of various SQL expressions on GP data extraction and manipulation performance: Select versus SQL cursor is good example. This is not the only warning – when you use SQL update, delete or insert query, you can damage GP DYNAMICS or company database tables

4. Integration Mapping. Your employees or traditional IT department contractors might be giving you the signal that they’ll integrate Microsoft Dynamics GP with your legacy Sales system. Microsoft as successor of Great Plains Software, knows that GP is mid-size ERP package and being such it requires consulting partner network to sell MRP software and do certified GP ERP installation and implementation. Of course your people could ultimately and theoretically be done with the GP implementing job, however you should understand the risks and learning curve cost impacts

5. Diving to Technology Ocean. GP technologies include: Microsoft Dexterity, SQL Server 2005 and 2000, GP ReportWriter, GP Modifier with VBA, Crystal Reports, eConnect and XML Web Services, GP Integration Manager with eConnect connectors. MS Sharepoint and GP Business Portal at this time are in market attacking mode, so if you need such practical modules as Electronic Document Delivery, Requisition Management (successor of eRequisition), Order Management (successor of eOrder)

6. Pervasive SQL or Ctree integrations. There are chances that your company had hard time in earlier 2000 and you lapsed to pay Microsoft Great Plains annual enhancement program. In this situation, if you plan to get new GP version, currently GP 10.0 license keys, you will have to undergo GP enhancement reenrollment procedure

Microsoft Great Plains 10.0 Integration Options, Part Two

admin — Wed, 23 Jun 2010 04:38:39 +0000

In the previous article “Microsoft Great Plains Integration Notes” we described standard integrating options and tools: GP Integration Manager, eConnect, SQL Stored Procedures and Dexterity. This is addition to the first article and here we will describe advanced scenarios: EDI (Electronic Document Interchange), combining Dexterity with eConnect to address multiple companies in GP user interface, GP integration with Java based applications

1. EDI. It is often considered by software developers as something very complex, where UNIX world is interchanging vendor records, vendor invoices and purchase orders to replenish company inventory or fulfill the order. However if you look at EDI realization, you will often realize that it is simply fixed width text file or combination of fixed width text fields with encrypted numeric fields, where numeric fields you can process and convert into text with relatively simple character processing programming. If you came to the point where on the input side you have fixed width text fields, what you need to do now is to create SQL insert into script and send records into GP tables. The second option is to get formatted fields via select statement and call eConnect methods to send Vendor Invoice into GP for example. In order to parse fixed width text fields in SQL select statement you should read books online and get answer there.

2. Dexterity and eConnect. GP users like Dexterity customizations, as these customizations are seamlessly integrated into GP user interface and security realm. However GP user interface assumes that you as GP user is logged into specific GP company and do your work in this company: enter invoices, post batches, etc. When you are designing customization with eConnect and Dexterity there is simple opportunity to break through single company. Dexterity allows you to call com objects or dll libraries, in turn com object could be written in .Net C# or VB, where you use ADO.Net constructions to switch SQL Server databases, staying for GP companies. As eConnect interface call is stored procedure, this is simple for programmer to call stored procedure in any database he or she likes. Considering legacy technologies, such as VBA scripting with Dex sanscript codes in and Continuum techniques – extension to switch Great Plains Dynamics modules; switching GP companies was always really difficult to accomplish in your integration, so eConnect, Dexterity and DLL combination seems to be very promising

3. GP and Java integrations. Reliable approach is to open eConnect interface via custom web services, which you can call from your EJB, J2EE, Java or Oracle application. Please note that GP is Microsoft realm and if you deploy non-Microsoft technologies such as DB2, PHP websites typically require technology integration testing