Export (0) Print
Expand All

Microsoft BizTalk Adapters for JD Edwards EnterpriseOne and OneWorld

Overview

Large companies today are filled with disparate systems containing overlapping functionality. Companies frequently support separate systems to handle manufacturing, financials, human resources (HR), and customers. Those companies that are disciplined enough to run on a single vendor’s line of business (LOB) applications are not necessarily better off than those running on applications from multiple vendors. It is likely that the vendor gained the application suite through acquisitions, and supports only custom integration between the individual applications.

Even companies that run on a single Enterprise Resource Planning (ERP) system that also handles HR and Customer Relationship Management (CRM) data are rarely able to handle the custom requirements of each organization. The result is that millions of dollars are spent on customizing the LOB application or developing an entirely separate application (a satellite system) to handle the custom functionality. (The advantage of creating a satellite system is that it is significantly easier than dealing with the LOB version upgrade problems that accompany the modification of source code in an LOB application.) Regardless—whether a company has multiple LOB applications, a plethora of satellite systems, or both—the data between systems needs to be sourced from a single master and synchronized across each application. Otherwise, the data becomes stale and worthless. Data synchronization is one of the problems that Microsoft® BizTalk® Server is designed to address, and with the addition of the LOB adapters in BizTalk Server 2006, applications such as PeopleSoft, JD Edwards, and Siebel can be smoothly integrated.

ERP Systems

ERP systems are a type of LOB system. In their early form, they were sold as a “magic bullet” solution to integrating an enterprise’s business, people, and processes. ERP systems were popularized in the 1980s and 1990s with the intention of integrating multiple business functions into a single application platform. Built by the likes of Oracle, PeopleSoft, JD Edwards, Siebel, SAP, and Baan, these ERP systems created application silos bounded by each vendor’s proprietary application technology. Inevitably there was a need to integrate ERP systems with each other or with other systems that provided additional functionality.

Figure 1: Typical LOB system integration scenario (partial integration)
Bb820914.c1cd4677-1e4f-4de4-b0a0-41cbe4746fa1(en-US,BTS.10).gif

Figure 1 depicts typical scenarios in which LOB system integration occurs with seemingly ad-hoc integration links needed to keep data synchronized. These include mergers and acquisitions that result in two companies, running two different ERP systems, that must share data through synchronization or real-time exchange. Another scenario where such integration occurs is when new systems are introduced with functionality not available within the ERP systems. For example, the implementation of a custom e-commerce system introduces the need for the customer to enter a sales order into the corporate Order Management System (OMS) in near-real time. Still another example is when there is no centralized organizational application strategy (due perhaps to “political boundaries” or to improper management), resulting in departments within the same company using different systems.

Integration and Interoperability

The need for integration prompted the need for external, or integration-based, APIs from ERP vendors. However, the APIs produced were clunky, proprietary, and required very specialized skill sets. The need for standards-based adapters based on a common pattern was apparent, and several vendors went to work to create adapter frameworks that would allow a developer to learn a single API for creating software to integrate with multiple ERP platforms. Some adapter vendors took this a step further to create adapters that were ready to use with integration platforms such as BizTalk Server 2006.

Figure 2: Typical integration scenario designed by using BizTalk Server and LOB adapters
Bb820914.35466ec2-2a36-4684-b982-a14cdc0b2a61(en-US,BTS.10).gif

This allows BizTalk Server to be used as a centralized integration broker, as shown in Figure 2, reducing the need for point-to-point or custom integrations between two systems. BizTalk Server 2006 provides a diverse set of LOB adapters to facilitate the exchange of information between a variety of ERP systems, and other external data repositories, through the use of a common technology. We will summarize important high-level technical points about the LOB adapters throughout this white paper.

Purpose and Advantages

The purpose of the LOB adapters is to enable companies to leverage their existing investments in their enterprise application infrastructure while mitigating risks inherent to integrating business systems. The following paragraphs discuss some advantages of using the adapters.

Reuse of Existing Business Logic

A common integration challenge faced by companies today is that much of their investment in the design and development of business logic cannot be leveraged when interfacing directly with the underlying databases. Use of a data transformation utility such as Data Transformation Services (DTS) or SQL Server™ Integration Services (SSIS) can often lead to data exchanges that violate critical business rules because these rules are implemented in application logic, and not in the databases. This also undermines the investment made in the LOB system’s business logic. By communicating directly with the LOB system at the database level, it is possible to introduce data that will be misinterpreted by the LOB system.

“Application adapters” allow integration platforms to interface with the “business logic layer” of the LOB system using each system’s proprietary interface mechanisms. By using application adapters, IT departments can create integrations that will exchange data while still adhering to the critical business rules that have been programmed into the business logic layer.

Specifically with BizTalk Server 2006, the Adapters for Enterprise Applications (the “LOB adapters”) enable run-time application integration while also providing key design-time functionality. BizTalk Server ports are configurable for connections to multiple instances of the LOB systems. “Wizards” are used in the Microsoft Visual Studio® .NET development environment to browse business object metadata and generate XSD schemas and orchestrations that can be consumed as part of the BizTalk Server development cycle.

Reduced Development Cost

Because the BizTalk Server LOB adapters communicate directly with the existing business logic layer on the LOB system, additional components that would otherwise be duplicated as part of an integration effort are not needed. Companies can avoid having to develop components for their integration projects that mimic the logic that already exists on the LOB systems.

Lower Change Management Risk

Eliminating the need for duplicated business logic greatly reduces the risks associated with managing changes to the LOB systems and any dependent systems. For example, if you have seven different processes all using distinct versions of the same business logic, a change in one could necessitate a change in all. However, it is possible that not all seven processes would be modified correctly or at all. Even if the changes were properly completed, imagine the resources expended in making the same change repeatedly or inaccurately.

Component/Package View of LOB Adapters

The LOB adapters consist of several components. You will find many of these processes running in Task Manager as you use the design-time and run-time components of the adapters:

  • Adapter Framework – The adapters are built on the BizTalk Server Adapter Framework. The Adapter Framework is a set of extensible APIs that enable developers to take advantage of relevant services of BizTalk Server when building adapters and connectors that integrate third-party applications. For more information, see How the Adapter Is Designed: The Adapter Framework.
  • Java Runtime – The Adapter Framework, which is used by the LOB adapters, is dependent upon the Java Runtime (version 1.4.3 or later).
  • Browser Agent – This process is used by the Adapter Framework and invoked by Visual Studio .NET. It retrieves and formats metadata from the LOB systems into XSD files that the BizTalk Server development environment can then consume and use. After five minutes of inactivity, it automatically shuts down to release any resources, such as memory, that may have been used. This process appears in Task Manager as browsingagent.exe.
  • Runtime Agent – This process is used by the Adapter Framework and is invoked by the BizTalk Server runtime (BtsNtSvc.exe) to call business functions on the LOB systems. Unlike the Browser Agent, the Runtime Agent does not shut down after a period of inactivity. This process appears in Task Manager as runtimeagent.exe.
  • Connectors, JAR files – JAR files contain the set of Java classes specific to the LOB system. The Adapter Framework exposes these classes as Java interfaces, which are used to communicate with the BizTalk Server design-time and run-time executables.

Figure 3 shows the high-level architecture of both the design-time and run-time components and how they interface with the LOB adapters and the LOB system.

Figure 3: LOB adapter process flow
Bb820914.ef291557-9aaf-462c-87f8-0ff148f9bcb2(en-US,BTS.10).gif

JD Edwards Architecture

JD Edwards OneWorld and EnterpriseOne are both based on a true client/server architecture. Business logic can be configured to run either on the client application or at the server. The BizTalk Adapters for JD Edwards leverage this architecture by calling business functions to run on the JD Edwards servers inside JD Edwards “kernel” processes.

Figure 4: JD Edwards client/server architecture
Bb820914.e997b2b7-8c6a-4f14-b15c-3bffa8acf43b(en-US,BTS.10).gif

To facilitate integration with third-party systems, JD Edwards provides interfaces for Web services, XML (through the JD Edwards proprietary remote transport, ThinNet), and file-based exchanges.

Figure 5: JD Edwards integration architecture
Bb820914.b4dd8f35-dc4f-4241-991b-a283421a1945(en-US,BTS.10).gif

The JD Edwards Web Services Gateway (WSG) was introduced with EnterpriseOne Tools Release 8.95. The BizTalk Adapters for JD Edwards do not use the WSG. Prior releases of OneWorld and EnterpriseOne relied on COM or Java connector technology, communicating via ThinNet by using either marshaled data structures or XML.

The JD Edwards LOB Adapters

The BizTalk Adapters for JD Edwards use Java connector technology to marshal business function (BSFN) calls via the JD Edwards proprietary remoting protocol, “ThinNet,” to a JD Edwards Logic Server. The Logic Servers are responsible for hosting kernels that receive remote function calls and run business functions.

Bb820914.461a44dc-92ca-4796-92ee-ae09ed4b7ee5(en-US,BTS.10).gif

The BizTalk Adapters for JD Edwards activate remote communications with the JD Edwards servers during both design time (to query for adapter metadata) and run time (to run business functions).

This section outlines the complex process of installing BizTalk Adapters for JD Edwards OneWorld and EnterpriseOne. Detailed installation procedures can be found online at: http://go.microsoft.com/fwlink/?LinkId=56392.

LOB System Expertise

An important note about installation of LOB adapters—and application adapters in general—is that multiple actors in technical roles for the LOB system (developer and/or administrator) will need to be involved during the installation process. Specifically for JD Edwards (OneWorld or EnterpriseOne), a system administrator and/or “CNC Specialist” will need to be involved in the installation process.

The following paragraphs outline the relevant BizTalk system actors (roles and computers), as well as the JD Edwards system actors. We will then outline the interactions between the actors of the two systems.

Procedures

The following is a high-level overview of the installation procedures for the BizTalk adapter for JD Edwards OneWorld. This information is not intended to replace Microsoft LOB adapter installation documentation, which is available online at http://go.microsoft.com/fwlink/?LinkId=56392. Understanding these concepts before installing the adapter will help you communicate resource requirements with your customer.

Relevant Roles and Systems

Multiple IT roles need to be involved with the installation of the LOB adapters. Development and administration experts for both BizTalk Server 2006 and the LOB system(s) need to be present and able to make changes on the LOB systems for the installation to succeed.

The following diagrams provide background about the roles and computers involved, and interactions of the typical BizTalk development cycle and JD Edwards development cycle.

Figure 6: Simplified sample BizTalk Server development life cycle, including roles and computers that are relevant to the process
Bb820914.e0d50213-7cb8-4b2e-bc01-e6872ee44968(en-US,BTS.10).gif
Figure 7: Simplified sample JD Edwards development life cycle, including roles and computers that are relevant to the process
Bb820914.33d4a7b9-b7c3-4294-9100-6f7530562a55(en-US,BTS.10).gif

As you can see, the system development life cycles for BizTalk Server and JD Edwards are similar. Knowing the particulars about each development life cycle can help BizTalk Server roles and JD Edwards roles communicate about the installation and development processes.

High-Level Process Overview

The installation process for the BizTalk Adapters for Enterprise Applications is often difficult to grasp due to the large number of roles and servers involved as part of that process. The following figure outlines the JD Edwards adapter installation process in a pseudo-sequence diagram to supplement the BizTalk Adapters for Enterprise Applications installation guide. It outlines from a high level the roles and computers involved, as well as the steps required to install the BizTalk Adapter for JD Edwards (OneWorld or EnterpriseOne).

Figure 8: BizTalk Adapter for JD Edwards installation process overview
Bb820914.8bcc92f1-b5aa-4606-a105-7c78da461ce0(en-US,BTS.10).gif

A successful installation is dependent on your ability (as a BizTalk Server consultant, developer, installer, or administrator) to communicate the requirements and installation procedures of the BizTalk Adapter for JD Edwards to the CNC specialist. The installation process is invasive to JD Edwards—that is, modifications to JD Edwards system configurations and package deployments require restarts of the JD Edwards services, which may interfere with normal operation of the JD Edwards application environment.

For information about installing Microsoft BizTalk Adapter for JD Edwards OneWorld, see the Microsoft BizTalk Adapters for Enterprise Applications installation guide. To ensure that you are reading the most up-to-date information, download the latest version of the guide at http://go.microsoft.com/fwlink/?LinkId=56392.

Development Overview

The development process for the BizTalk Adapters for Enterprise Applications requires close interaction with a JD Edwards application developer to determine which objects and functions to call in a JD Edwards application from BizTalk Server.

The following diagram illustrates the sequence of events that must take place when developing solutions with the BizTalk Adapter for JD Edwards (OneWorld or EnterpriseOne).

Figure 9: BizTalk Adapter for JD Edwards development process overview
Bb820914.ca415904-2ec6-4f9a-94d2-0f3aa8dd0dc5(en-US,BTS.10).gif

BizTalk Adapter Send Handler- Calling into JD Edwards from BizTalk Server

The steps that require interaction with a JD Edwards developer are annotated with an asterisk (*) below.

  1. (*) Determine the business function(s) that will be used to enter data into OneWorld. This can be a rather involved process. You should consult a JD Edwards analyst or developer to determine which functions to call.
  2. Configure a send port with the appropriate adapter parameters.
  3. (*) Configure the jdearglist.txt file for any fields that must be left-padded/right-justified. This step is required due to the requirement for some JD Edwards data items to be right justified in a fixed-width field. Some example data items that may require such treatment include “szBranchPlant.”
  4. Generate XSD schemas (metadata) based on the business functions specified by the JD Edwards analyst or developer in step 1.
  5. Create your BizTalk solution with additional schemas, maps, and orchestrations as needed to call the JD Edwards business functions.
  6. (*) Create a test set of data by using the first schema in the series of calls as test data. A JD Edwards developer will need to tell you which fields are required and any code lists that need to be enforced (code lists are also called “User Defined Codes” (UDCs) in JD Edwards).
  7. (*) Troubleshoot any business function errors with the JD Edwards developer.

Send Ports

To use the BizTalk Adapters for JD Edwards, you must have a properly configured send port. The send port contains parameter data used by the adapter to connect to JD Edwards at both design time and run time. Adapter required parameters listed in the following two tables.

Adapter Required Properties

Parameter Name Description or Examples

Host

The IP or resolvable name of the JD Edwards Enterprise or Logic server. For environments with more than one server, use the “security server.”

JAVA_HOME

The directory where the Java runtime is installed.

JDEdwards Environment

This indicates which set of logic and business data on the JD Edwards system the adapter will access. Common names include:

  • DV7333 (for Development)
  • PY7333 (for Prototype)
  • PD7333 (for Production)

JD Edwards JAR files

(OneWorld)

This is a semicolon-delimited list of JAR files that reside on the local BizTalk server. This list must include:

  • Connector.jar and Kernel.jar – These jar files must be copied over from a JD Edwards workstation.
  • JDEJAccess.jar –Installed with the Adapter for JD Edwards.
  • BTSLIBInterop.jar – This file must be created on a JD Edwards development workstation using the “GenJava” process. See Figure 8 for an overview and the installation guide for a detailed description of the process.

JD Edwards JAR files

(EnterpriseOne)

This list must include:

  • Connector.jar, Kernel.jar, database.jar, jdeutil.jar, log4j.jar, and xerces.jar – These JAR files must be copied over from a JD Edwards workstation.
  • Database JDBC drivers – e.g. For Microsoft SQL Server: msbase.jar, mssqlserver.jar, and msutil.jar.
  • JDEDynAccess.jar – Installed with the Adapter for JD Edwards.

User name and

Password

General login information for the JD Edwards environment. The user must exist in the JD Edwards system and have access to the appropriate environments (as indicated in the “JDEdwards Environment” parameter listed above).

Port

The TCP port on which the JD Edwards server is listening. By default, OneWorld listens on TCP port 6009. EnterpriseOne listens on TCP port 6010. However, the CNC specialist or JD Edwards administrator may have reconfigured this. Consult the customer’s CNC specialist for more information about the TCP port they have configured their servers to listen on.

Bootstrap Data Source Required Properties (EnterpriseOne only)

Parameter Name Description or Examples

Data Source Name

Configured for the specific database on which JD Edwards is running.

(See BizTalk Adapter for JD Edwards EnterpriseOne documentation.)

Data Source Owner

Configured for the specific database on which JD Edwards is running.

(See BizTalk Adapter for JD Edwards EnterpriseOne documentation.)

Database Server name

Configured for the specific database on which JD Edwards is running.

(See BizTalk Adapter for JD Edwards EnterpriseOne documentation.)

Database Server port

Configured for the specific database on which JD Edwards is running.

(See BizTalk Adapter for JD Edwards EnterpriseOne documentation.)

Database Type

Configured for the specific database on which JD Edwards is running.

(See BizTalk Adapter for JD Edwards EnterpriseOne documentation.)

Physical Database Name

Configured for the specific database on which JD Edwards is running.

(See BizTalk Adapter for JD Edwards EnterpriseOne documentation.)

Once configured properly, both the design-time tools (Add Adapter Metadata Wizard) and run-time components of the adapter will function properly.

A note about browsing adapter metadata from the BizTalk Adapters for JD Edwards OneWorld and EnterpriseOne: JD Edwards OneWorld uses an API call to retrieve a list of libraries and objects from the OneWorld Logic Server. JD Edwards EnterpriseOne uses a database call to retrieve a list of libraries and objects from the EnterpriseOne logic server, so it will need database access to the JD Edwards “System” and “Object Librarian” database.

Finding the Right Business Function

Finding the right business function to use for your integration can be a challenging step of developing integration solutions with BizTalk Server and the Adapters for JD Edwards. It requires knowledge of JD Edwards application development and debugging. You should consult a JD Edwards developer for help to determine which JD Edwards business functions BizTalk Server will need to call, in what sequence, and in which libraries they belong.

After you’ve gathered the JD Edwards library, object, and function names you’ll need for your integration, you are ready to run the Add Adapter Wizard. Figure 10 illustrates a listing of JD Edwards OneWorld libraries (e.g., CSALES) and JD Edwards business function objects/services (e.g., B4200310) available for metadata generation. One or more method calls will be included with each object selected, represented as schema root nodes.

Figure 10: Add Adapter Wizard for JD Edwards adapters
Bb820914.d9057b12-c0f1-4003-a606-be82fb4f0f59(en-US,BTS.10).gif

The Add Adapter Wizard generates three files for each service (object) selected:

  1. An object-level definition xsd (e.g., B4200310Service_obj.xsd).
  2. API metadata definition xsd (e.g., B4200310Service_ B4200310_x5d.xsd) – This is the primary schema for the JD Edwards business function object and contains multiple root-level nodes that expose the various methods available in the business function object. See Figure 11.
  3. A BizTalk orchestration (e.g., BizTalk Orchestration.odx) that includes a multipart message type for each method exposed by the JD Edwards object and port type definitions, which can be used to make function calls into JD Edwards. See Figure 12.
Figure 11: A sample schema generated by the JD Edwards adapter
Bb820914.941215bb-3836-4587-89ad-49113d41076b(en-US,BTS.10).gif
Figure 12: A sample orchestration generated by the JD Edwards adapter
Bb820914.081d4beb-be93-4369-a192-3e2c3640d1ac(en-US,BTS.10).gif

Use of Orchestration

In general, multiple JD Edwards business functions are called in series to complete a business action or event.

For example, entering sales order data into JD Edwards (using the B4200310 object) requires the use of a minimum of four different function calls into JD Edwards from BizTalk Server:

Function Name
(<LibraryName>.<ObjectName>.<FunctionName>)
Purpose

COPSALES.B4200310.F4211FSBeginDoc

Creates an order header record in a temporary table.

COPSALES.B4200310.F4211FSEditLine

Creates order line records in a temporary table.

COPSALES.B4200310.F4211FSEndDoc

Commits the order header and lines by copying records from the temporary table to the master business tables.

COPSALES.B4200310.F4211ClearWorkFile

Clears the temporary tables.

Each of these function calls requires a different message to be sent to JD Edwards and the calls must be made in the sequence shown. Though this sequence of calls could conceivably be performed by using Content Based Routing (CBR) without orchestration, using orchestration provides for easier troubleshooting, the addition of logic, and explicit error handling using the Scope shape and exception handlers.

BizTalk Receiving Messages- Triggering Data Out of JD Edwards into BizTalk Server

The BizTalk Adapters for JD Edwards do not include receive handlers. Fortunately, BizTalk Server offers a variety of “out-of-the-box” adapters that can assist in this process, including the file-based adapters, various database adapters, and Web service adapters.

The following sections outline options for sending data outbound from JD Edwards to BizTalk Server.

Use JD Edwards Events (EnterpriseOne Only)

EnterpriseOne supports three types of event mechanisms for outbound transaction notifications: “Z events,” “Real-time events,” and “XAPI events.” In each of these mechanisms, key field data is sent to a third-party application (BizTalk Server) from JD Edwards. Custom C++ (Win32®) and/or JD Edwards development may be required to create a subscriber that can transfer data from Z-tables to the appropriate BizTalk receive handler (e.g., HTTP, SOAP, or File).

Refer to JD Edwards interoperability documentation for detailed information about each of these event-based mechanisms.

Use JD Edwards Flat-File Exchange

JD Edwards applications include facilities for flat-file exchanges. Used primarily for electronic data interchange (EDI) exchanges, these flat files can also be used to transport data outbound from JD Edwards to third-party systems, such as BizTalk Server. BizTalk Server can then use the File adapter to pick up these flat files for processing.

Configure BizTalk Server to Poll JD Edwards Interface Tables (“Z-tables”) for Triggers from JD Edwards Client Applications

This method requires a direct database connection from BizTalk Server to the JD Edwards databases. In this method:

  1. BizTalk Server polls a JD Edwards Z-file by using a database adapter. (JD Edwards supports SQL Server, Oracle, and DB2; BizTalk Server database adapters are available for each of these.)
  2. A trigger record is written to a JD Edwards Z-table by the JD Edwards application after a transaction is completed. This record should include key fields for the transaction.
  3. BizTalk Server reads and updates (or deletes) the Z-table record, and then makes the appropriate business function calls into JD Edwards to retrieve records related by the key fields in the Z-table record.

Common Errors

Error Number and Message (in Event Log) Resolution

JDE0002 – Jar files missing

Verify path to jar files that are configured in the send port.

JDE0027 – Unable to acquire JDE Connection object

Verify credentials and access to jar files.

JDE0043 – Wrong App Server, Port, Environment, Path for configuration, File, User, Password

Verify login credentials.

JDE0048 – jdearglist.txt is missing or empty

Update jdearglist.txt file w/ list of parameters so that they are automatically right justified. Schemas must be regenerated if this file is updated.

Limitations

As with all application adapters, you can only push or pull one data item per call. You cannot add, update, or retrieve multiple items from JD Edwards in a single call (e.g., you cannot pull a list of items matching a given search criteria).

JD Edwards data structures often contain parameters that require right justification with left padding. Schemas generated by the “Add adapter metadata” process include information about these fields. There is a workaround for this limitation. The jdearglist.txt file (found in: C:\Program Files\Microsoft BizTalk Adapters for Enterprise Applications\<Your J.D. Edwards system>\Config) is used by the adapter to determine fields that require right justification. Configure this .txt file with the list parameters using the following naming pattern: <ObjectName>.<FunctionName>.<Parameter>

Line of Business (LOB) System An application used in business

Enterprise Resource Planning (ERP) System

A software package used by a company to manage important parts of its business. An ERP system can be considered a type of LOB system.

Application Adapter

Software used by integration platforms to enter and extract data from ERP/LOB systems.

  • Business Function (BSFN)
  • Table (TBLE)
  • Data Structure (DSTR)
  • Business View (BSVW)
  • Batch Job (UBE)

Object types available in JD Edwards and their respective abbreviations.

Configurable Network Computing (CNC)

A proprietary architecture created by JD Edwards in which applications and logic can run on either servers or workstations.

The purpose for this design is to be able to offload business logic processing from servers to workstations or other special-purpose servers to reduce CPU load on the servers.

For example, some servers can be dedicated to running business functions used in interactive applications, while others are used to run batch jobs (UBEs).

JD Edwards Computer Roles

Server Role Description

Deployment Server

The server from which packages are built and deployed.

Enterprise Server

A server with a combined role of Logic Server and Data Server.

Logic Server

The server that hosts all logic components, including DLLs, specification files, JDE Kernel engines, Batch engines, and external APIs.

Database Server

The server that hosts all databases for JD Edwards.

Workstation

A workstation on which the JD Edwards OneWorld client application is installed.

Workstation with “development objects”

A workstation on which the JD Edwards OneWorld client application is installed along with all source code and specification files for the purpose of developing these objects using JD Edwards tools.

Other JD Edwards Terminology

Terminology / Skill Set Description

“CNC” Specialist

(CNC = Configurable Network Computing)

aka JD Edwards System Administrator

Members of IT staff responsible for installing JD Edwards applications and for building and deploying packages for JD Edwards OneWorld or EnterpriseOne.

Business Analysts

Members of the business organization responsible for communicating the business requirements of both the business systems (ERP) and the integration points that will be implemented by using BizTalk Server.

Developers

Members of IT staff responsible for developing JD Edwards objects (tables, views, data structures, business functions, applications, and batch jobs).

Packages

A package in JD Edwards contains one or more changes to the business objects used within JD Edwards applications.

  • A “full” package contains all libraries and objects, is typically 1.5 GB in size or larger, and takes hours to build.
  • An “update” package contains a subset of libraries and objects selected by the CNC specialist or administrator.
  • A “server” package contains objects destined for the server.
  • A “client” package contains objects destined for client workstations. Server and client packages cannot be interchanged because they are compiled differently.

Logic components

Made up of both DLLs and “spec files” that are proprietary to JD Edwards. These logic components contain specifications for JD Edwards applications, batch jobs, tables, views, and business functions.

Object Librarian

A database that carries metadata about all objects in JD Edwards. The object librarian is key to enabling BizTalk Server design tools to enumerate business functions via the B5500901 business function.

Jay Lee is a Partner and Chief Technologist at Anaheim-based eBI Solutions, LLC (http://www.ebisolutions.net) where he and his team help customers succeed in their business and IT initiatives in Enterprise Application Integration (EAI), Business-to-Business Integration (B2Bi), Business Process Management (BPM), and Business Intelligence. Jay holds a BA in Physics from UCLA and is pursuing an MBA at the Marshall School of Business at USC. He is a member of the Microsoft BizTalk Virtual Technical Specialist team. He speaks, writes, and trains regularly on topics related to BizTalk Server architecture, development, and administration. Jay lives with his wife Emily in Orange County, CA.

Mark Michaelis is the owner of intelliTechture, a small business dedicated to training and consulting in Microsoft technologies as well as the IDesign architect specializing in WCF and VSTS. Mark was recognized by Microsoft as a Microsoft MVP for Visual Studio Team System and he wrote the official courseware for VSTS for Microsoft. Mark holds an MS in Computer Science from the Illinois Institute of Technology and he serves on several Microsoft Software Design Review teams including WCF, C#, and VSTS. Mark speaks at developer conferences both nationally and internationally and has written several articles and books, in addition to maintaining a blog (http://mark.michaelis.net/blog). His recent book is Essential C# 2.0 (Addison-Wesley, 2006).

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft