Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
First posted :
03/24/2008
Times viewed :
1737
BizTalk Adapter SAP Overview
The BizTalk
Utilities Adapter
is aimed at providing BizTalk Server 2004 the ability to interact with SAP.
It provides
interfaces to SAP via IDocs and SAP .NET Connector generated proxies. SAP .NET
Connector generated proxies provide access to SAP BAPIs and RFCs.
Redesigned
and developed to allow for integration into the new BizTalk Server 2004 BizTalk
Utilities Adapter
Framework.
Developed
in C#.NET it provides a fast optimized mechanism for communicating with SAP
Applications from BizTalk Server 2004.
The BizTalk
Utilities Adapters are fully integrated into the Visual Studio .NET environment providing
Developers with an enhanced Visual Studio .NET Experience when configuring.
The BizTalk
Utilities Adapter
is extremely easy to install and configure. All tasks performed when
configuring the BizTalk
Utilities Adapter is Wizard Driven.
System Requirements
The
following are the minimum software requirements for the BizTalk
Utilities Adapter:
Microsoft
Enterprise Instrumentation Framework
Microsoft
BizTalk Server 2004
Enterprise Instrumentation
Framework (EIF)
The BizTalk
Utilities Adapter
utilizes EIF for writing event and tracing information to the Application Event
Log and Windows Trace Files.
The
Microsoft Enterprise Instrumentation framework provides unified management,
eventing, and diagnostic tracing services for enterprise applications in a
production environment. Enterprise Instrumentation enables developers to
consistently instrument enterprise applications, which are increasingly
decoupled and distributed, and enables support staff to use a
"white-box" approach to monitoring and diagnosing application health,
faults, or other internal conditions.
Every
released software application, regardless of size or complexity, imposes a
common requirement on the business that the application serves: it must be
managed to ensure that the application provides its services correctly and
reliably during its operational lifetime. Instrumentation plays a key role in
application manageability, allowing a particular software or hardware element
to publish — or be queried for — relevant information. Examples of common
instrumentation mechanisms include performance counters, event logs, Windows
2000 Event Trace, and Windows Management Instrumentation (WMI). These
mechanisms are often complementary, as in the example of querying an event log
through a WMI provider.
Achieving
consistent instrumentation across all enterprise applications is a difficult
task. Today, enterprises that build applications on Microsoft platforms must
instrument their applications by directly writing to event logs, performance
counters, third-party instrumentation APIs, or their own common instrumentation
wrappers and libraries. Implementing and supporting the various forms of
instrumentation brings additional challenges, given the distributed nature of
today's n-tier, Web-enabled applications.
Operations
staff must be able to trace specific paths through the system, not just monitor
individual events and event sources. Logically related events from physically
different servers need to be correlated. The instrumentation itself must be
suitable for a production application; instrumentation overhead must minimally
affect application throughput. Finally, organizations must be able to leverage
as many existing management tools and infrastructure as possible, to monitor
and troubleshoot the enterprise applications they support.
Key
features of this framework are:
Unified
programming model, suitable for both enterprise developers and system
developers.
Operations teams.
Scriptable
configuration layer, allowing operations teams to configure how events are
raised or logged from an application.
Support
for raising or logging events through WMI, Windows Event Log, and Windows Event
Tracing, a high-speed kernel-mode tracing system.
Correlation
of events to business processes or operations with Request Tracing, which
allows operations staff to troubleshoot requests across a distributed
application.
In
Addition, the BizTalk
Utilities Adapter incorporates the following enhancements to EIF:
The
Level of Tracing and Eventing for the BizTalk
Utilities Adapter can be set by running a Wizard in
Administration Microsoft Management Console (MMC) Snap-In. Levels that can
currently be set is for Production, Testing/QA and Development.
Tracing
Sessions can be enabled or disabled from the MMC Snap-In.
Trace
Files can be viewed and exported from the MMC Snap-In.
Performance Monitors
The BizTalk
Utilities Adapters feature an extensive set of Windows Performance Counters with which
the BizTalk
Utilities Adapters can be monitored and Fine Tuned.
Administration Snap-In
The
Microsoft Management Console (MMC) Administration Snap-In is used to perform
the following tasks:
As standard
within all of the BizTalk
Utilities Adapters, inbound messages can be archived
to a File Location or Microsoft Message Queuing (MSMQ). Support for Archiving
to BizTalk Server 2004 will be added in Future.
IDoc Support
The BizTalk
Utilities Adapter
provides for the sending and receiving of IDoc to and from BizTalk Server 2004.
IDoc Schema Generation
IDoc
Schemas are generated from within Visual Studio .NET from a Wizard. SAP Release
2, 3 and 4 IDoc Schemas can be generated by the Wizard.
Schema
information is extracted from the SAP system via a SAP Destination.
Multiple
IDoc Schemas can be generated for a single BizTalk Server Project. IDoc Control
and Status Records can be automatically promoted. Property Schemas for Control
and Status records will be generated automatically if the options are
specified.
In addition
the following options can be specified:
Control
Specify if a Control Record Property Schema
will be generated.
Data Types
Specify if Data Types for the Schema should be
derived from the SAP Data Types for the IDoc.
Status
Specify if a Status Record Property Schema will
be generated.
Version
Specify the SAP Release for which the IDoc
Schema should be generated. SAP Release 2, 3 and 4 is supported.
IDoc Receive Pipeline
The IDoc
Receive pipeline is used to identify, route and validate IDocs received from
SAP Systems.
IDoc Receiver
The IDoc
Receiver is responsible for receiving IDocs for SAP Systems and submitting them
to BizTalk Server.
The
following Properties can bet set within the Receiver:
Recycle Interval
A remote SAP System may disconnect for the IDoc
receiver due to System or Network failures. Here you can specify the interval
at which the Receiver will reconnect to the remote SAP System.
SAP Destination
Here you select a SAP destination as defined in
the Administration Snap-In. New SAP Destinations can be generated from this
interface by selecting <New Destination>.
Archiving
Specify how you want to Archive Messages
received.
Encoding
Specify the Encoding in which IDocs should be
received from the SAP System.
All
messages are received within a Transaction.
IDoc Transmitter
The IDoc
Transmitter is responsible for sending IDocs to SAP Systems. It can be defined
statically or invoked dynamically by setting the Uri of a Port within your
Orchestration to idoc://<SAP Destination>.
When
defining it dynamically other properties can also be set.
The following
Properties can bet set within the Transmitter:
SAP Destination
Here you select a SAP Destination as defined in
the Administration Snap-In. SAP Destinations can also be created from this
interface by selecting <New Destination>.
Batch Size
Specify the Size of Message Batches. A Value of
0 switches Batching off.
BAPI and RFC Support
The BizTalk
Utilities Adapter
allows for the execution of SAP BAPIs and RFCs from BizTalk Server 2004. SAP
.NET Connector generated proxies are used to invoke BAPIs and RFCs.
Proxy Schema Generation
SAP .NET
Connector Proxy Schemas are generated from within Visual Studio .NET from a
Wizard.
Schema
information is extracted from the SAP .NET Generated Proxy.
The Proxy
class is then selected.
And the
Method.
Request and
Response Schemas are generated.
Proxy Transmitter
The Proxy
Transmitter is responsible for invoking SAP .NET Connector Proxies. It can be
defined statically or invoked dynamically by setting the Uri of a Port within
your Orchestration to sapproxy://<SAP Destination>.
When
defining it dynamically other properties can also be set.
The
following Properties can bet set within the Transmitter:
SAP Destination
Here you select a SAP Destination as defined in
the Administration Snap-In. SAP Destinations can also be created from this
interface by selecting <New Destination>.
Batch Size
Specify the Size of Message Batches. A Value of
0 switches Batching off.
Statefull Bapi
This option should be set to true when calling
Statefull Bapi Objects.
Throw Exception when no Records are
found
Specifies if an Exception should be thrown when
no records are returned.
The BizTalk
Utilities Adapter
will determine if the SAP .NET Connector Proxy should be invoked within a
Transaction and request a new Transaction from the SAP System.
To learn more about these and other features, download an evaluation copy of BizTalk
Utilities