webMethods Designer Training (1).ppt

(1)

webMethods CoE

Designer Training

Puneet Saxena Integration Architect

(2)

Introduction to Designer

Document Types

Flow Services

Mapping

Java Services

Monitoring Services

Flat File Handling

Web Services

JDBC Adapter

(3)

3

(4)

4

Objectives

• At the end of this section, you will be able to:

– Understand various perspectives in designer – Basic webMethods configurations

(5)

5

Designer

• Designer is an integrated, Eclipse-based design environment providing powerful and comprehensive features that enables to model, develop and maintain enterprise-wide business processes and applications, build ESB projects, and SOA implementations. Software AG Designer is also fully integrated with many runtime

servers like My webMethods Server, ESB, EntireX, ApplinX, Tamino, CentraSite, and Natural to provide visibility, management, and

debugging capabilities to the end user in a single tool.

(6)

6

• Business analysts and developers work in this environment to design and create process models, user interfaces, task applications, and Web applications.

• Developers can build both webMethods ESB services as well as standard Web services to provide customized solutions to support business process management, SOA initiatives, and integration projects.

• Application developers work in this environment to create and

maintain NaturalONE applications and services with Web-based user interfaces, SQL-based access to relational and non-relational data sources.

(7)

7

Workspace, Workbench And Perspectives

• The workspace is the directory where all the work will be stored. It can be stored anywhere in the local system, just select a path and give a name.

• Workbench refers to the desktop development environment. The Workbench aims to achieve seamless tool integration and controlled openness by

providing a common paradigm for the creation, management, and navigation of workspace resources. Each Workbench window contains one or more perspectives.

• A perspective defines the initial set and layout of views in the Workbench window. It also provides a set of functionality aimed at accomplishing a

specific type of task, or working with a specific type of resource. Perspectives define visible action sets, which can be changed to customize a perspective. One or more perspectives can exist in a single Workbench window.

(8)

8

• To open a perspective

Click the Open Perspective button on the shortcut bar on the left side of the Workbench window. (This provides the same function as the Window > Open Perspective menu on the menu bar.).

To see a complete list of perspectives, select Other... from the drop-down menu

(9)

9

Process Development Perspectives

• Process Development perspective includes basic process design functionality and property information to allow the non-developer to create processes; allows uploading processes for analysis only. • Process Developer mode provides advanced configuration and

property access to further define processes. Business Analyst mode displays only basic properties in the Properties view, basic

preferences in the Preferences window, and basic functions on the main toolbar.

• The Process Debugging perspective includes functionality that allows process debugging, and also supports design and property

information of the Process Development perspective; allows

uploading processes for analysis as well as building and uploading processes for execution.

(10)

10

Process Projects, Process, Pools, Swimlane

• Process projects serve as the parent structures for Designer

processes and their assets. A single process project can contain one or more processes.

• A process is the top-level asset in a process project. It contains steps and logic, and it is the asset that is ultimately built and executed in the Process Engine, and uploaded to the Process Audit Database for analysis.

• Pools are constructs that help organize process project. A Designer process can have one internal pool and unlimited external pools. • Swimlanes are subdivisions of pools. Where a pool typically

represents a single process, swimlanes typically serve to further subdivide a process. Each swimlane designates an actor, which becomes a property inherited by all steps in the swimlane.

(11)

11

Steps, Subprocesses

• Create steps onto the process and connect them to create a process. Steps are categorized by what they do, specified in their properties, and also by their function in the process.

• Types of Steps – Activity Steps – Receive Steps – Reply Steps

– Adapter Notification (AN) Steps – Publish Steps

– Terminate Steps – Gateway Steps

• A subprocess is not a self-contained process. It can exist only inside its parent process. A subprocess is a group of steps in a container, and is treated as a step in the process.

(12)

12

Step Inputs and Outputs

• Each step in a process has information that flows into and out of it. Information flowing into a step is called input, and information flowing out of a step is called output.

• Process data assigned in Designer to flow in and out of steps needs to be mapped to physical data that the underlying services require in order for the process to execute.

• Step inputs and outputs are used to define flow signatures, branching and looping logic in the process, data logging for examination at run time, and KPIs.

• Data can enter the process in two ways

– In a receive step, a subscription document can trigger or join the process, and output data for that step and into the pipeline

– In an activity step, the step can output new process data into the pipeline.

(13)

13

Step Transition

• Transitions indicate the flow of control in the process being passed from one step to another. Specialized transition types, as well as splits and branches, are permitted from each step. These transitions each have a label and a description that are distinct from the condition itself.

• Transition conditions are based on logical data, rather than physical data, and can be specified in the Process Development perspective.

• Step transition types: – Split – Branch – Join – Join Timeout – If Condition – Else – Error – Timeout

– Step Iterations Exceeded – Unsatisfied Join

(14)

14

Join Conditions, Subscription Filters

• Join conditions occur when a step has multiple input transitions.

• Join conditions can use AND, OR, or Unsynchronized OR statements in their logic.

• Complex join conditions by using a combination of NOT/AND/OR/ Unsynchronized OR statements, parentheses, and multiple

transitions to create a join string, using each transition’s source Label (step name) as the identifier can also be created.

• Subscription filters provide the option to limit which instances of a

document are able to trigger or join a process, based on the values of specific fields in the subscription document

(15)

15

Correlation Services

• Correlation Services are used to allow external documents to join running process instances. Each receive step that can start a new process instance has a Correlation Service property. At least one receive step in a process must be designated Allow this step to

start new process instance (a start step).

• Correlation services are written in webMethods Developer or in the flow service editor in Designer, and establish or match the correlation ID used by a process instance

(16)

16

Building and Uploading Processes

• Enabling the Process Developer capability (using Process Developer mode) allows to build a process and upload it to the Process Audit database for

execution. Without the Process Developer capability (using Business Analyst mode), a process can be uploaded to the Process Audit Database for

analysis only; the process is not built, and it cannot be executed.

• When a process is build, Designer creates the elements that execute at run time based on the information in the process, such as steps, subscription filters, transitions, and conditions. Designer then places these generated run-time elements on the Integration Server and uploads information about the process to the Process Audit Database.

• Each step in a process model is associated with a specific Integration

Server Name. Designer places the run-time elements associated with a step

on the physical server that is mapped to the Integration Server Name for the step.

(17)

17

Process Debugging and Process Simulation

• Debugging a process involves running it with tools that allows to inspect the way it behaves with real data, and to see how that data behaves as it travels through the pipeline.

• A debugging session requires that process starts with a receive step with an IS document input. Process Debugging supports

subscription, simple service (Web service), and JMS receive protocols.

• The Process Simulation feature provides a mechanism to simulate processes and see details about how they run. By simulating a

process, or multiple processes, time, energy, and resources can be saved that might otherwise be misspent on deploying solutions that do not fit business needs.

• Simulation provides the opportunity for testing and tweaking

processes in the design phase, before they ever reach production, or even a test environment.

(18)

18

Different Perspectives

• Java development • Platform Plug-in

• JDT (Java Development Tooling) Plug-in • Plug-in Development

• CentraSite Plug-ins

• Data Tools Platform Plug-in • Data Tools Platform

• Eclipse Modeling Framework (EMF) • Web Tools Project

• webMethods CAF (Composite Architecture Framework) • webMethods Task

(19)

19

(20)

20

(21)

21

Objectives

• At the end of this section, you will be able to: – create Document Types

– reference Document Types in the Pipeline – discuss options for Document Type Validation – Publish / Subscribe documents to broker

(22)

22

IS Document Type

• An IS document type contains a set of fields used

to define the structure and type of data in a

document (IData object). IS document type is

used to specify input or output parameters for a

service or specification. An IS document type can

also be used to build a document or document

list field and use as the blueprint for pipeline

(23)

23

• IS document types can provide the following benefits:

– Using an IS document type as the input or output

signature for a service can reduce the effort required

to build a flow.

– Using an IS document type to build document or

document list fields can reduce the effort needed to

declare input or output parameters or the effort/time

needed to build other document fields.

– IS document types improve accuracy, because there

is less opportunity to introduce a typing error typing

field names.

– IS document types make future changes easier to

implement, because it helps to make a change in one

place (the IS document type) rather than everywhere

(24)

24

Creating a Document Type

• Create an empty IS document type and define the structure of the document type by inserting fields.

• Creating an IS Document Type from an XML Document, DTD, or XML Schema.

• Creating an IS Document Type from an E-form Template stored on the file system or in a content repository

(25)

25

Document Reference

• An IS document type (including a publishable document type) can be used to build a document reference or document reference list field. By referencing an IS document type instead of creating a new one, it reduces the time required to create fields and maintain better

consistency for field names. Referencing fields especially useful for information that is repeated over and over again, such as address information.

(26)

26

Pipeline References

• A pipeline reference is where a variable in a document reference or document reference list in Pipeline view is linked to another variable, assigned a value, or dropped.

• When an IS document type is edited, the changes affect any

document reference and document reference list variables defined by that IS document type. The changes might make pipeline references invalid.

(27)

27

Publishable Document Types

• A publishable document type is a named schema-like definition that describes the structure and publication properties of a particular kind of document. Essentially, a publishable document type is an IS

document type with specified publication properties such as storage type and time-to-live.

• In a business process, a published document can start or join a process.

• In a publication environment that includes a Broker, each publishable document type is associated with a Broker document type. Designer provides tools that can be used to ensure that these two document types remain synchronized.

• In an integration solution that uses the publish-and-subscribe model, services publish instances of publishable document types, and

triggers subscribe to publishable document types. A trigger specifies a service that the Integration Server invokes to process the

(28)

28

Triggers

• Broker/local triggers establish subscriptions to publishable document types and specifies how to process instances of those publishable document types.

• A condition associates one or more publishable document types with a single service.

• The publishable document type acts as the subscription piece of the Broker/local trigger. The service is the processing piece. When the Broker/local trigger receives documents to which it subscribes, the Integration Server processes the document by invoking the service specified in the condition.

(29)

29

Creating a Publishable Document Type

• To create a publishable document type, set publication properties for an IS document type. Properties that can be set include: specifying whether instances of the publishable document type should be saved in memory (volatile storage) or saved on disk (guaranteed storage) during processing, and specifying how long instances of the

publishable document type should remain on the Broker once they are published.

• If the Integration Server on which a session is connected to a Broker, when an IS document type publishable is created, Integration Server automatically creates a Broker document type and assigns the Broker document type a name. This name corresponds to the following

format: wm::is::folderName::documentTypeName. If a document type with this name already exists on the Broker, the Integration Server appends “_1” to the Broker document type name.

(30)

30

• If the Integration Server on which a session is not connected to a Broker, the publishable document types that is created can be used only in local publishes. That is, instances of the publishable

document types can only be published and subscribed to with in the same Integration Server.

• Designer creates a publishable document type automatically when using an e-form template as the source for the IS document type.

(31)

31

About the Envelope Field

• All publishable document types contain an envelope (_env) field. This field is a document reference to the pub:publish:envelope document type. The envelope is much like a header in an e-mail message. The pub:publish:envelope document type defines the content and

structure of the envelope that accompanies the published document. The envelope records information such as the sender’s address, the time the document was sent, sequence numbers, and other useful information for routing and control.

(32)

32

Adapter Notifications and Publishable

Document Types

• Adapter notifications determine whether an event has occurred on the adapter's resource and then sends the notification data to

Integration Server in the form of a published document.

• Each adapter notification has an associated publishable document type. When an adapter notification is created in Designer, Integration Server automatically generates a corresponding publishable

document type.

• Designer assigns the publishable document type the same name as the adapter notification, but appends PublishDocument to the name.

(33)

33

Document Type Validation

• XML schema • FlatFile Schema

• Document Type Defination • Publishable Document Type

(34)

34

Validation

• Input/Output Validation - In input/output validation, the validation engine in webMethods Integration Server validates the inputs and/or outputs of a service against the declared input and output parameters of the service.

• Document Validation - Validate an individual document (IData object) in the pipeline instead of the entire pipeline.

• Pipeline Validation - Pipeline validation is the process of verifying the contents of the pipeline against an IS document type.

• XML Validation - XML validation is the process of verifying the structure and content of an XML document against an IS schema. • Validation within Java Service -

(35)

35

(36)

36

(37)

37

Objectives

– Describe the capabilities of webMethods Flow

• Repeat • Loop • Branch • Exit

• Sequence

– Try /Catch Flow implementation – Run your Flow services

– Debug your Flow Service

(38)

38

Services

• Services are method-like units of logic that operate on documents. They are executed by Integration Server. Services are build to carry out work such as extracting data from documents, interacting with back-end resources and publishing documents to the Broker.

• Integration Server is installed with an extensive library of built-in services for performing common integration tasks. Adapters and

other add-on packages provide additional services that ca be used to interact with specific resources or applications. webMethods

graphical implementation language, flow, enables to quickly

(39)

39

Flow Service

• A flow service is a service that is written in the webMethods flow language. This simple yet powerful language encapsulate a

sequence of services within a single service and manage the flow of data among them.

• Any service can be invoked within a flow (including other flow services).

• Flow services created using Designer are saved in XML files on Integration Server.

• Although flow services are written as XML files, they are maintained in a format that can only be created and understood by Designer and webMethods Developer. Flow service cannot be created with a text editor.

(40)

40

Flow Step and Pipeline

• A flow service contains flow steps. A flow step is a basic unit of work (expressed in the webMethods flow language) that webMethods Integration Server interprets and executes at run time. The webMethods flow language provides flow steps that invoke services and flow steps that let allow to edit data in the pipeline.

• The pipeline is the general term used to refer to the data structure in which input and output values are maintained for a flow service. It allows services in the flow to share data. The pipeline starts with the input to the flow service and collects inputs and outputs from subsequent services in the flow. When a service in the flow executes, it has access to all data in the pipeline at that point.

(41)

41

Control Steps

• Control steps that allow to direct the execution of a flow service at run time. The control steps allows to:

 Conditionally execute a specified sequence based on a field value.  Retry a specified sequence until it succeeds.

 Repeat a specified sequence (loop) for each element in an array field.

• Various Control Steps are:  Sequence

 Loop  Branch  Repeat  Exit

(42)

42

Sequence

• Groups a set of flow steps into a series. The SEQUENCE step is implicit in most flow services (that is, the steps in a flow service are treated as a series). However, at times it is necessary to explicitly group a subset of flow steps using SEQUENCE so that they can be treated as a unit.

(43)

43

Loop

• Executes a set of flow steps once for each element in a specified array.

(44)

44

Branch

• Executes a specified flow step based on the value of a specified variable in the pipeline.

• Branch can be build in two ways:

– Branch on a switch value (switch case) – Branch on an expression (if-else)

• Branch on a switch value and an expression for the same BRANCH step is not possible.

(45)

45

Repeat

• Re-executes a set of flow steps up to a specified number of times based on the successful or non-successful completion of the set. • Repeat can be used as:

– Re-execute (retry) a set of steps if any step within the set fails. – Re-execute a set of steps until one of the steps within the set

(46)

46

Exit

• Controls the execution of a flow step (for example, abort an entire flow service from within a series of deeply nested steps, throw an exception without writing a Java service, or exit a LOOP or REPEAT without throwing an exception).

• Exit step can be specify exit from:

– The nearest ancestor (parent) LOOP or REPEAT flow step to the EXIT flow step.

– The parent flow step of the EXIT flow step.

– A specified ancestor flow step to the EXIT flow step. – The entire flow service.

(47)

47

Invoke and Map

• Invoke executes a specified service, it request a service within a flow. • Map performs specified editing operations on the pipeline (such as

mapping variables in the pipeline, adding variables to the pipeline, and dropping variables from the pipeline). It adjust the contents of the pipeline at any point in a flow service.

(48)

48

Run Flow Service

• Designer invokes the service (just as an ordinary IS client would) and receives its results. The service executes once, from beginning to

end (or until an error condition forces it to stop). The service executes on the Integration Server on which there is an open session, or on the Integration Server specified in the launch configuration.

• Results from the service are returned to Designer and displayed in Service Result view. This allows to quickly examine the data that the service produces and optionally change it or save it to a file.

(49)

49

Debugging Flow Services

• Debugging a service can be done as:

– Execute a flow service one flow step at a time and view the results of each step.

– Set breakpoints to specify points in a flow service at which processing should stop.

– Change the values passed to each step in the flow service. – Use the Step Over (execute the current flow step ), Step Into

(open a child flow to debug the individual flow steps within it), and Step Out (Return to the parent flow from a child) commands during a debug session

.

– Disabling Flow Steps, Transformers, and Conditions. – Modifying the Flow Service Pipeline while Debugging.

(50)

50

Save and Restore the Flow Service Pipeline

• Because the pipeline contains the data that a service operates

against, the ability to save and restore the pipeline while debugging a service is something frequently wanted to do.

• Saving the Flow Service Pipeline while Debugging – Saving the Pipeline to a File

• save the pipeline to ocal file system

• save the pipeline to the IntegrationServer_directory\pipeline directory on the machine on which Integration Server reside. – Saving the Pipeline at Run Time

• The pipeline gets saved automatically to a file at run time by using the Pipeline Debug property

(51)

51

• Restoring the Flow Service Pipeline while Debugging

Restoring a pipeline is useful to inspect the values in a particular pipeline file (perhaps one that contains the pipeline from a failed service). Additionally, it is useful in many debugging situations. There are three ways to restore the contents of the pipeline:

– manually load the saved pipeline into the Variables view while debugging in Designer.

– automatically load the saved pipeline at run time by using the Pipeline Debug property .

– programmatically load a saved pipeline at run time by invoking pub.flow:restorePipelineFromFile at the point where to modify the pipeline

(52)

52

(53)

53

(54)

54

Objectives

• At the end of this section, you will be able to: – perform complex mapping

– use transformers

(55)

55

Mapping data in Flow service

• Since systems rarely produce data in the exact format that other systems need, flow services needs to be build that perform data

transformations. Data transformation resolves differences in the way data is represented within documents that applications and systems exchange.

• In Designer, data transformations can be accomplished by mapping data.

(56)

56

• By mapping following types of transformations can be accomplished – Name transformations - This type of transformation resolves

differences in the way data is named.

– Structural transformations - This type of transformation resolves differences in the data type or structure used to represent a data item.

– Value transformations - This type of transformation resolves differences in the way values are expressed

(57)

57

Basic Mapping

• Basic mapping are the tasks to manage the pipeline contents and the values of variables in the pipeline. Various tasks are:

– Link variables to each other – Assign values to variables

– Drop variables from the pipeline – Add variables to the pipeline – Variable substitution

(58)

58

Transformers

• Transformers are the services use to accomplish value

transformations in the Pipeline view. Only transformer can be inserted into a MAP step.

• Transformers are well suited for use when mapping data from one document format to another. When mapping data between formats, there is a need to perform several name, structure, and value

transformations. By using transformers, the flow service in which mapping data between formats could potentially consist of a single MAP step where transformers and links between variables handle all of the data transformations. In this way, entire document-to-document mapping is done in a single view.

(59)

59

Inserting a Transformer

• Transformers can only be inserted in a MAP step.

• Any service can be used as a transformer, including flow services, C services, and Java services.

• The transformers inserted into a MAP step operate on the same set of pipeline data.

• The output of one transformer cannot be used as the input of another transformer in the same MAP step.

• Transformers in a MAP step are independent of each other and do not execute in a specific order. When inserting transformers, assume that Integration Server executes the transformers concurrently at run time.

• In a MAP step, Designer only displays the links between pipeline variables and transformers. Designer does not display any implicit linking for a MAP step.

(60)

60

(61)

61

(62)

62

Objectives

– describe the capabilities of webMethods Java Services – write Java Services

– understand the role IData plays in writing Java Services

– understand how different Integration Server data structures are exposed to Java services

– understand various ways of invoking Java services and generating Java code

(63)

63

Java Service

• A Java service is a public static method in a Java class file on

Integration Server. Java services follow a simple naming scheme: – The service name represents the Java method name.

– The interface name represents the fully-qualified Java class name.

• Because Java class names cannot contain the “.” character, services that reside in, nested folders are implemented in a class that is

scoped within a Java package. All Java services that reside in the same folder are methods of the same class.

• When Java service is build, the system automatically combines the service into the class file associated with the folder in which it is created in.

(64)

64

IData Object

• The IData object is the universal container that services use to receive input from and deliver output to other programs.

• It contains an ordered collection of key/value pairs on which a service operates.

• An IData object can contain any number of key/values pairs

(elements). The keys in an IData object must be Strings. The values can be any Java objects (including IData objects).

(65)

65

Get and Set IData Objects(IData Cursors)

• Getting data from and putting data into IData elements takes two steps. First, position the cursor at the IData element. Next, get or set the data in that element.

• The class that used to position a cursor in an IData object is IDataCursor.

• The IDataCursor class contains methods for performing basic cursor operations such as placing the cursor at the first, last, or next element in the object.

• After positioning the cursor on the element, the getValue or setValue methods to read or write the value of that element, respectively can be used. This class also provides methods for inserting new

(66)

66

(67)

67

(68)

68

Objectives

• At the end of this section, you will be able to: – set up logging for Services and Processes

– describe the key features of My webMethods Monitor – monitor services

(69)

69

Audit Logging

• Audit logging for webMethods products provides important data that needs to monitor webMethods system activity and correct problems. Integration Server maintains most of the audit logging data in the webMethods.

(70)

70

Types of Logging

• Error Audit Logging - Error audit logging provides data about exceptions thrown by services running on Integration Server

• Session Audit Logging - Session audit logging provides data about sessions opened on Integration Server by Developer, Designer,

third‐party clients, and other servers.

• Service Audit Logging - Service audit logging provides data about flow and coded (for example, Java) services that run in Integration Server

• Security Audit Logging - Security audit logging provides data about security‐related administrative and operational events that occur on Integration Server. Administrative events are configuration changes related to Integration Server security activities. Security audit logging provides data about security‐related administrative and operational events that occur on Integration Server. Administrative events are

(71)

71

• Document Audit Logging

• Guaranteed Delivery Audit Logging - If configure the guaranteed delivery capability in Integration Server is configured, guaranteed delivery audit logging provides data about guaranteed delivery transactions.

• Business Process Audit Logging - Business process audit logging provides data for business processes modeled in Designer that run on Integration Servers

• Task Audit Logging - Tasks are created in Designer and run on My webMethods Server

(72)

72

Logging Setup

• Integration Server writes error, session, service, security,

document, guaranteed delivery, and Mediator transaction audit

logging data to files or database tables collectively called the

IS Core Audit Log.

• Integration Server writes business process, integration

process, and task audit logging data to database tables

collectively called the Process Audit Log

• Levels of Logging

– perSvc - set up customized logging on a

service

‐by‐service basis in Developer or Designer.

– Brief - The logger writes start and failure or start and

success log entries for every service every time the

service is called, either directly or by another service.

– Verbose - Same as Brief, except that the logger also

(73)

73

Logging Level

• Fatal - Failures that end operations in such a way that the operations cannot successfully continue without user intervention. Failure is VERY likely to affect other operations or products.

• Error - Same as Fatal, except that existing error handling renders the failure unlikely to affect other operations or products.

• Warn - Problems that do not end operations, or unexpected or unusual conditions that might signal impending failure • Info - Success of an event that you need to know about.

• Debug - Code-level statements recording unusual conditions or decisions that might lead to errors.

• Trace - Code-level statements recording program flow and state during normal execution.

• Off - No information for the product or facility is written to the server log.

(74)

74

Service Audit Logging

• Track when services start, their status, and their duration. • Track whether services completed successfully or failed.

• Record the client that called the service, and the Integration Server port on which the client connected.

(75)

75

Business Process Audit Logging

• Identify business processes.

• Record the path that business processes took at run time.

• Track when business processes and business process steps started, changed status, and ended.

• Track whether business processes and steps completed successfully or failed.

(76)

76

My webMethods and webMethods Monitor

• My webMethods is a Web-based, monitoring and administration user interface for managing webMethods components. Logging into My webMethods, means logging into all webMethods components that are incorporated into My webMethods.

• webMethods Monitor displays data that webMethods Integration

Server and webMethods Optimize for Process have logged. Data can be logged about business processes, services, and documents.

• To access Monitor functionality, log in to the My webMethods user interface. The Administrator user account is defined at installation; this user account is assigned the password manage.

(77)

77

Monitor and My webMethods User Interface

• View data logged by other webMethods products. • Resubmit services and documents

• Monitor, suspend, resume, and resubmit process instances

• Enable process models and define settings that are used by running process instances of those models

• Generate reports about process instances, process models, task users, and task roles

• Archive or delete audit data from the IS Core Audit Log and Process Audit Log database components

• Monitor functionality is in the Applications section in both the

(78)

78

Administration Section

• User Management - Define users, groups, and roles and configure access to Monitor privileges.

• Business Processes - Enable process models for execution and define settings that are used by running process instances of the models

• Archive Audit Data - Archive or delete audit data from the IS Core Audit Log and Process Audit Log database components

• System Settings - Identify the Integration Server with which the My webMethods Server is to interact.

(79)

79

Monitoring Section

• Process Instances - View the details about individual process

instances, including drilling down to view information about the steps within a process.

Suspend, resume, and stop process instances.

• Services - View audit data that Integration Server have logged for services. Resubmit services.

• Documents - View documents that have been logged to the IS Core Audit Log database component. Resubmit documents

(80)

80

(81)

81

(82)

82

(83)

83

Objectives

– describe the webMethods Flat File Architecture

– create a Flat File Dictionaries and Schemas using Developer – parse delimited, fixed-length, variable-length, and complex Flat

Files

(84)

84

FlatFile

• Flat files present complex hierarchical data in a record–based storage format, which unlike XML does not embed structural

information (metadata) within the data. In other words, the metadata of a flat file is separated from the data and contained in a flat file

schema.

• A single logical record of application data is externalized as a set of records without any structural information. Therefore, the application receiving the flat file must have knowledge of the structure of the flat file, through the flat file schema, to read the flat file.

• Flat files enables to send data to any application in a mutually agreed upon format so that the data in the files can be read and processed

(85)

85

Architecture

• All flat files consist of a list of records containing fields and composites

• Fields are atomic pieces of data. • Composites contain multiple fields.

• Records (also known as segments) are sequences of fields and/or composites.

• To communicate using flat files, users must create a flat file schema that contains a particular flat file’s structural information, including how to identify records and separate those records into fields.

• webMethods can exchange all types of flat files but can process only certain types of flat files.

(86)

86

Flat File Schema and Dictionaries

• A flat file schema is the blueprint that contains the instructions for parsing or creating a flat file and is created as a namespace element in the webMethods Integration Server. This blueprint details the

structure of the document, including delimiters, records, and repeated record structures. A flat file schema also acts as the model against which an inbound flat file can be validated.

• A flat file dictionary is a repository for elements that refers from flat file schemas. This allows to create record definitions in a dictionary that can be used across multiple flat file schemas. Reusing record definitions reduces the amount of memory consumed by a flat file schema.

• The decision to define records in a flat file dictionary or in a flat file schema depends on the type of flat files that needs to be parsed.

(87)

87

Parsing of Records using Flat File Schema

• Record Parsers - A record parser breaks a flat file into individual records

• In webMethods, there are four record parser:

– Delimited Record Parser - This parser expects a specific delimiter to indicate the end of a record, a character or character

representation or hex-decimal value or octal value or unicode characters.

– Fixed Length Record Parser- This parser splits a file into records of the same pre-specified length. This parser measures the lengths and positions of records in terms of bytes, rather than characters – Variable Length Record Parser- This parser expects each record

to be preceded by two bytes that indicate the length of the record – EDI Document Type Record Parser -This parser is used only for

EDI flat files and provides additional functionality needed to properly parse EDI documents

(88)

88

• Record Identifiers - A record identifier looks at a record and

extracts an identifier out of the data. The identifier is then used

to connect the record definition in a flat file schema with a

particular record in the flat file. The name of the record

definition must match the value obtained by the record

identifier.

• In webMethods there are two methods of record identifications:

– Starts at position - record identifiers compare the value

that occurs in the record, at the specified offset, to all the

record names defined in the flat file schema.

– Nth Field record identifiers use the value of the specified

field as the record identifier. These identifiers count from

zero (0).

(89)

89

Format Services

• Service that formats the field String in a flat file schema or dictionary and ensures that the value of the String meets the format restrictions of the format service.

(90)

90

(91)

91

(92)

92

Objectives

• At the end of this section, you will be able to: – create Web Service provider nodes

– Use Web Service consumer nodes – work with custom fault documents

(93)

93

Web Services

• A Web service is a collection of functions that are packaged as a single unit and published to a network for use by other software programs. Web services are building blocks for creating open, distributed systems.

• Designer uses Web service descriptors to encapsulate information about Web services and uses Web service connectors to invoke Web services

(94)

94

Web Service Descriptors and Connectors

• Web service descriptor (WSD) is an element on Integration Server that defines a Web service in IS terms. The WSD encapsulates all the information required by the provider or the consumer (requester) of a Web service. The WSD contains the message formats, data

types, transport protocols, and transport serialization formats that should be used between the consumer (requester) and the provider of the Web service. It also specifies one or more network locations at which a Web service can be invoked. In essence, the WSD

represents an agreement governing the mechanics of interacting with that service.

• Web service connector is a flow service that Integration Server

creates at the time it creates the consumer Web service descriptor. Web service connector contains the information and logic needed to invoke an operation defined in the WSDL document used to create the consumer Web service descriptor.

(95)

95

• A provider Web service descriptor defines a Web service that is hosted on the Integration Server, that is, a service “provided” to

external users. A provider Web service descriptor will expose one or more IS services as operations, which can be published to a registry as a single Web service. External users can access the Web service through the registry and invoke the IS services remotely.

• A consumer Web service descriptor defines an external Web service, allowing Integration Server to create a Web service

connector (WSC) for each operation in the Web service. The Web service connector(s) can be used in Designer just like any other IS flow service; when a connector is invoked it calls a specific operation of a Web service.

(96)

96

Exposing IS Services as Web Services

• Any service in any Integration Server package can be turned into a Web service. Integration Server provides an environment for executing services efficiently and securely. It receives and decodes requests from clients, calls the requested services, and encodes and returns the output to the clients. To expose an IS service as a Web service, use the IS service as an operation in a provider Web service descriptor

• A provider Web service descriptor (WSD) is created from one or more IS services or from a single WSDL document, and is designed to allow the IS services to be invoked as Web services over a network. The provider Web service descriptor contains all the data required to create a WSDL document for the IS Web service, as well as the data needed at run time to process the request and response.

• A service first provider WSD refers to provider WSDs created from an

existing service on Integration Server. The IS service becomes an operation in the provider WSD. Integration Server uses the existing service signature as the input and output messages for the operation. Operations and bindings ca be added to a service first provider WSD.

(97)

97

• A WSDL first provider WSD refers to a provider WSD created from an existing WSDL document or from a Web service acquired from a

UDDI registry. In this case, Designer uses the message and

operation definitions from the WSDL to generate a “placeholder” flow service for each operation encountered in the WSDL, along with IS document types defining the input and output signature of the

generated flow services and then implement any required logic within the placeholder flow service. Operations or bindings cannot be added to a WSDL first provider WSD.

• The provider WSD can be published to a UDDI registry (or other publicly accessible server) as a Web service, which can be invoked remotely by an external user. A Web service provider can also

(98)

98

Invoking Web Services

• Create a consumer Web service descriptor in Integration Server to invoke Web services located on remote servers. It contains all the data from the WSDL document that defines the Web service, as well as data needed for certain Integration Server run-time

properties.

• When creating a consumer Web service descriptor from a WSDL document, Integration Server creates a Web service connector for each operation contained in the WSDL document.

• The Web service connector is a flow service that:

– Uses an input and output signature that corresponds to the input and output messages of the Web service operation. – Contains flow steps that create and send a message to the

Web service using the transport, protocol, and location information specified in the Web service.

– Contains flow steps that extract data from the output message returned by the Web service.

(99)

99

(100)

10 0

(101)

10 1

Objectives

• At the end of this section, you will be able to: – configure an Adapter Connection

– create Adapter Services – create Notification Services

(102)

10 2

JDBC Adapters

• The webMethods JDBC Adapter is an add‐on to the webMethods Integration Server that enables to exchange data with relational databases through the use of a JDBC driver. The adapter

provides seamless and real‐time communication with the database without requiring changes to existing application infrastructure.

• Using the JDBC Adapter, webMethods Integration Server clients can create and run services that execute transactions to retrieve data from, and insert and update data in, relational databases. • The JDBC Adapter supports the following databases:

– 􀂄 DB2 for OS/390, AS/400, Universal Database (UDB) – 􀂄 IBM Informix

– 􀂄 Microsoft SQL Server – 􀂄 Oracle

– 􀂄 Sybase – 􀂄 Teradata

(103)

10 3

Adapter Connection

• The JDBC Adapter connects to a database through a JDBC driver at run time. One or more connections can be created at design time to use in integrations. The number of connections created, and the types of those connections, depend on the types of databases connected to and integration needs.

• JDBC Adapter connections contain parameters that the Integration Server uses to manage connections to the database so that they can be used by the JDBC Adapter to provide services. Connections are configured using the webMethods Integration Server Administrator tool. Must have webMethods administrator privileges to access the JDBC Adapter’s administrative screens.

(104)

10 4

Transaction Types

• NO_TRANSACTION

The connection provides no transaction control over the operations being performed. That is, the connection automatically commits (Auto Commit) all operations.

• LOCAL_TRANSACTION

The operations on the same connection in one transaction boundary will be committed or rolled back together..

• XA_TRANSACTION

Allows the connection to support two‐phase transactions executed across multiple databases. In one transaction boundary, all of the operations on multiple connections will be committed or rolled back together.

A transaction boundary means the scope of the transaction, from the beginning to the end of a transaction. It can be in one adapter service, one flow service, one Java service, or several steps in a flow service

(105)

10 5

Adapter Services

• Adapter services allows to connect to the adapters resource and initiate an operation on the resource from the Integration Server.

• Adapter services can be called from flow or Java services to interact with database tables. The adapter services perform database

operations by calling JDBC APIs. The Integration Server then uses adapter connections defined earlier to execute the adapter services. • Adapter services are based on templates provided with the JDBC

Adapter. Each template represents a specific technique for doing

work on a resource, such as using the SelectSQL template to retrieve specified information from a database.

• An adapter service template contains all the code necessary for interacting with the resource but without the data specifications. These specifications needs to be provide to create a new adapter service.

(106)

10 6

Adapter service Type and Templates

Adapter Service

Type

Adapter Service Template

Description

Select SQL SelectSQL Retrieves specified information from a

database table.

Insert SQL InsertSQL Inserts new information into table.

Update SQL UpdateSQL Updates existing information in table

Batch Insert SQL BatchInsertSQL Inserts new information into table when

dealing with a large volume of data.

Batch Update SQL BatchUpdateSQL Updates information in table when

dealing with a large volume of data.

Delete SQL DeleteSQL Deletes rows from a table

Custom SQL CustomSQL Defines and executes custom SQL

Dynamic SQL DynamicSQL Defines and executes a SQL statement

(107)

10 7

Adapter Notifications

• An adapter notification monitors a specified database table for

changes, such as an insert, update, or delete operation, so that the appropriate Java or flow services can make use of the data.

• JDBC Adapter notifications are polling‐based. That is, the Integration Server will invoke the notification periodically based on the polling interval.

(108)

10 8

Adapter Notification Types and Templates

Notification Type Notification Template

Description

Insert Notification InsertNotification Publishes notification of insert operations on table

Update Notification UpdateNotification Publishes notification of update Operations on table

Delete Notification DeleteNotification Publishes notification of delete operations on table

Basic Notification BasicNotification Polls a table for data using a SQL Select operation.

Stored Procedure Notification

StoredProcedure Notification

Publishes notification data by calling a stored procedure inside database

Ordered Notification OrderedNotification Publishes notification data for multiple insert, update, or delete operations on multiple

(109)

10 9

(110)

11 0

(111)

11 1

Objectives

– Describe the Java Exception Handling procedure

– Distinguish between checked and unchecked exceptions – Throw exceptions from Java

– Catch exceptions in Java and Flow

– Use built-in Services to help debug your Services – Debug Services using a debugger

(112)

11 2

Classifying error types

• Application Error

The result of business process or application failure, or a designation assigned by a developer.

• Expected System Error

The predictable result of a known invalid action. These errors are thrown by the server or its components (adapters) and are

manifested as Java exceptions. • Unexpected System Error

The unexpected result of a system failure, use of incompatible software, or starvation of resources, memory, disk space, or any other event.

(113)

11 3

• Most webMethods Integration Server development is in one of two languages -- Flow and Java.

• For Java development, standard exception handling available is using Try-Catch blocks. This logic is well-known. When throwing

errors inside of webMethods Java services, though, discretion should be used. It is a clean API practice to handle as much exception logic as possible from within the throwing service. Using defensive

programming will help to avoid unwanted failures. Only when the

failure is beyond the developer's control should the Inetgration Server be notified via a Service Exception.

• For Flow development, webMethods makes available several

exception handling techniques. The BRANCH operator is handy for managing logic and application errors. The EXIT operator can be used to exit from an entire Flow or just a section of Flow.

(114)

11 4

Handling error notifications

• How error notifications are handled once caught is required business logic for any integration and must be addressed during the

Requirements Gathering phase of a project.

• The most common error reporting method is email notification. An error should be classified and reported to any relevant applications as well as delivered via email to developers. This approach helps to deal with critical issues quickly. A generic Error Handling service can be written to manage these tasks

(115)

11 5

Throwing errors

• In order to use Exception Handling services, we must write code that throws an error to be caught.

• Using Flow, call the EXIT operator and provide a detailed message for the failed action

(116)

11 6

Using Flow-based Try-Catch Blocks

• Another technique for handling Flow exceptions is to create a Try-Catch block

• The technique for creating Try-Catch blocks in Flow is as follows: SEQUENCE (EXIT on SUCCESS), Label: MAIN

SEQUENCE (EXIT in FAILURE), Label: TRY Try block Flow goes here

SEQUENCE (EXIT on DONE), Label: CATCH Catch block Flow goes here

(117)

11 7

(118)

11 8

(119)

11 9

(120)

12 0

webMethods Designer Training (1).ppt

webMethods CoE

Designer Training

Introduction to Designer

Table of Contents

Document Types

Flow Services

Mapping

Java Services

Monitoring Services

Flat File Handling

Web Services

JDBC Adapter

Objectives

Designer

Workspace, Workbench And Perspectives

Process Development Perspectives

Process Projects, Process, Pools, Swimlane

Steps, Subprocesses

Step Inputs and Outputs

Step Transition

Join Conditions, Subscription Filters

Correlation Services

Building and Uploading Processes

Process Debugging and Process Simulation

Different Perspectives

Objectives

IS Document Type

• An IS document type contains a set of fields used

to define the structure and type of data in a

document (IData object). IS document type is

used to specify input or output parameters for a

service or specification. An IS document type can

also be used to build a document or document

list field and use as the blueprint for pipeline

• IS document types can provide the following benefits:

– Using an IS document type as the input or output

signature for a service can reduce the effort required

to build a flow.

– Using an IS document type to build document or

document list fields can reduce the effort needed to

declare input or output parameters or the effort/time

needed to build other document fields.

– IS document types improve accuracy, because there

is less opportunity to introduce a typing error typing

field names.

– IS document types make future changes easier to

implement, because it helps to make a change in one

place (the IS document type) rather than everywhere

Creating a Document Type

Document Reference

Pipeline References

Publishable Document Types

Triggers

Creating a Publishable Document Type

About the Envelope Field

Adapter Notifications and Publishable

Document Types

Document Type Validation

Validation

Objectives

Services

Flow Service

Flow Step and Pipeline

Control Steps

Sequence

Loop

Branch

Repeat

Exit

Invoke and Map

Run Flow Service

Debugging Flow Services

.

Save and Restore the Flow Service Pipeline

Objectives

Mapping data in Flow service

Basic Mapping

Transformers

Inserting a Transformer