BPM steps

[Former Member]

Hi,

Please explain me BPM steps

Thanks in advance..

[Former Member · Accepted solution]

Hi Ginger ,

Business Process Management (BPM) has become a critical part of enterprise development.business process management

Business process management (BPM) is a systematic approach to improving an organization's business processes. BPM activities seek to make business processes more effective, more efficient, and more capable of adapting to an ever-changing environment. BPM is a subset of infrastructure management, the administrative area of concern dealing with maintenance and optimization of an organization's equipment and core operations.

A business process is a set of coordinated tasks and activities, conducted by both people and equipment, that will lead to accomplishing a specific organizational goal. The Business Process Management Initiative (BPMI), a non-profit organization, exists to promote the standardization of common business processes, as a means of furthering e-business and business-to-business (B2B) development. To this end, the organization has developed the Business Process Modeling Language (BPML), an Extensible Markup Language (XML)-based metalanguage for modeling business processes.

BPM(Business Process Management) is a structured approach that models an enterprise's human and machine tasks and the interactions between them as processes. BPM software uses a dashboard interface that offers a high-level view of the operation that typically crosses departmental boundaries. The dashboard integrates with all the applications that perform processes as well as related databases and can be used to trigger the start of a unit of work.

Evolving from document management, workflow and enterprise application integration (EAI), a BPM system can monitor and analyze tasks in realtime and set off alerts when specified limits are exceeded or a response is not received within a specified time.

Management for People/Machine Systems

For decades, systems that are entirely automated have more or less taken care of themselves. However, operations requiring a mix of people and machine procedures employ BPM as a higher-level management system that keeps track of them both.

Over time, a BPM system can provide historical data of human-machine interactions that might be extremely difficult to obtain from information systems, especially disparate systems from several departments or systems running on different platforms.

The BPM Suite (BPMS)

A BPM system may comprise a variety of independent packages or a comprehensive business process management suite (BPMS), which includes tools for modeling and analysis, application integration, business rules support, business intelligence (BI), activity monitoring and optimization. Advanced BPMSs provide a development tool for creating forms-based applications, which are often the start of many business processes.

An introduction to Business Process Management

http://www.avelon.nl/downloads/Introduction_BPM.pdf

business process management

http://whatis.techtarget.com/definition/0,,sid9_gci1088464_tax304528,00.html

BUSINESS PROCESS MANAGEMENT WITH SAP NetWeaveru2122

http://www.sap.com/platform/netweaver/pdf/BWP_NetWeaver_BPM.pdf

Business Process Management Essentials

http://www.glintech.com/downloads/BPM%20Essentials%20with%20Open%20Source.pdf

Business Process Management

http://www.seeburger.es/fileadmin/es/pdf/SEEBURGER_-_Business_Integration_Server__TA000714BPM_.pdf

BPM Process Patterns Repeatable Designs for BPM Process Models

http://edocs.bea.com/albsi/docs55/pdfs/BPM%20Process%20Patterns%20White%20Paper.pdf

Business Process Management -Modeling to Execution

http://www30.sap.com/korea/company/events/techday05/img/data_06.pdf

BUSINESS PROCESS MANAGEMENT (BPM)

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ed49db90-0201-0010-c4a5-c52...

BPM Process Patterns:Repeatable Design for BPM Process Models

http://www.bptrends.com/publicationfiles/05%2D06%2DWP%2DBPMProcessPatterns%2DAtwood1%2Epdf

Patterns: SOA Foundation - Business Process Management Scenario

http://www.redbooks.ibm.com/redbooks/pdfs/sg247234.pdf

A BPM Roadmap

/people/marilyn.pratt/blog/2007/10/12/clubhouse-las-vegas-a-bpm-roadmap

cheers!

gyanaraj

****Pls reward points if u find this helpful

[Former Member]

HI

BPM STEPS:

BPM Process Step types

Messaging relavent:

Receive: Receive message (can trigger process) / Modus Open S/A-Bridge

Send: Send message synchronously or asynchronously / Send acknowledgement / Mode Close S/A-Bridge

Transformation: Split, merge or convert messages

Receiver Determination: Get a list of receivers for subsequent send steps

Process flow control

Block

Block hierarchy is basis for visibility of container elements (local variables)

Deadline can be defined for block

Exception handling u2013 multiple exception handlers (branches) possible

Dynamic modes: dynamic parallel (ParForEach), dynamic sequential (ForEach)

Loop (While): Repeat steps while a condition is TRUE

Fork: Define independent processing branches

Switch: Define processing branches based on conditions

Control: Terminate process / Trigger exception /Trigger alert

Container Operation: Assign value to element / Append value to multiline element

Wait: Incorporate delay u2013 usually used to set start time for next step

Undefined: No function u2013 can be used as place holder or for test purposes

Block oriented design

In a block-oriented modeling paradigm, every split structure has a corresponding join structure thus facilitating properly closed structures. This paradigm relates to well-known structured programming concepts. It also provides effective means for restricting structural modeling errors (e.g. deadlocks) in the process models and allows hierarchical abstraction. Block orientation guides the user and makes sure that only valid processes can be created.

You can define blocks in a sequence or nest them within one another. However, a block cannot extend beyond any existing block boundaries. The outermost block of a process is always the process itself.

The block hierarchy is the basis for the visibility/scope of container elements (local variables).

Container Process data

Simple XSD types: for process control elements like counters

Abstract Interface: For messages, which are defined by using the corresponding asynchronous abstract interface and which are used in receive or send steps, for example.

Receiver: For a receiver list, which is determined from a receiver determination step, and which can be used in a send step.

Multiline: For example, if you want to collect messages in a container element, you must define this element as a multiline container element.

PROCESS CONTAINER AND LOCAL CONTAINER

For each block, you can define container elements.

Elements of a superordinate container are visible in subordinate containers.

Elements of a subordinate container are not visible in superordinate containers.

Container elements defined in the process container are visible in all blocks.

To define a container element in a block container, select the container in the editing area and then define the container element in the object area.

To define a container element in the process container, make sure that no block is selected in the editing area and then define the container element in the object area.

CORRELATION

You use a correlation to assign messages that belong together to the same process instance. A correlation joins messages that have the same value for one or more XML elements. A correlation is therefore a loose coupling of messages. At design time, a correlation enables you to define which message a receive step must wait for, without knowing the message ID.

For example, in a process, receivestep_1 receives the message purchaseorder, while receivestep_2 receives the message salesorder. Receivestep_1 creates a correlation that defines that the corresponding sales order must have the same purchase order number. Receivestep_2 uses this correlation. This means that an instance of the process processes a purchase order and the corresponding sales order, which has the same purchase order number.

You can activate a correlation from either a receive step or a send step.

A correlation is normally valid within the whole process and can be activated and used for the whole process. However, you can also define a correlation as a local correlation by assigning it to a particular block. You can only activate and use a local correlation in the block that it is assigned to.

Receive Step to Start a Process

Can be the first step of the process or first step of a fork, a block or a loop. In the case of the latter, the fork, block, or loop must be the first step in the process.

If the process contains further receive steps you can correlate their messages with the message from the first receive step. To do so, specify the correlations you want to activate.

For each correlation you must specify how you want the elements of the correlation container to be filled when the correlation is activated. You can use the whole process container for this purpose. If you specify multiple correlations, then the message to be received must satisfy all correlations.

Assigning Messages to Receive Steps

A receive step waits for a message as soon as the process has reached the receive step and the relevant correlation has been activated. If a message arrives for which there is no waiting receive step, then the message is received by the process and stored temporarily. As soon as the relevant receive step is activated, the system automatically assigns it the message that was received first for the relevant message interface, which satisfies the correlation used in the receive step. A message is only ever assigned to one receive step, even if multiple receive steps are waiting for a message from the same message interface. In the following cases, multiple receive steps can wait for a message from the same message interface:

Receive steps arranged one after the other: The first message that arrives is assigned to the first receive step, the second message is assigned to the second receive step, and so on. Therefore, the first message is not assigned to all receive steps that are waiting for a message from this message interface.

Receive step in a loop: If the process has not reached the receive step by the time that the message arrives, the process receives the message and places it in a queue. As soon as the process reaches the receive step and the relevant correlation is active, the system assigns the receive step the oldest message from the queue. If the process reaches the receive step but the queue is empty, then the process waits until a new message arrives.

Multiple receive steps in a fork: If multiple receive steps in forks are waiting for messages from the same message interface, then an inbound message is only assigned to one receive step (at random). The remaining receive steps must continue to wait.

You can only define one sync/async bridge per integration process. This comprises the following steps (for details see the Process Patterns lesson):

Synchronous Receive (Opening Receive): Receives the Request message from the synchronous business system and opens the sync/async bridge. The receive step must be the first step in the integration process. In the receive step you specify the synchronous interface receiving the message from the synchronous business system. The integration process is started when the message is received. The message type of the message to be received and the request message from the synchronous interface must be identical.

Asynchronous Send: Sends the received Request message asynchronously to the asynchronous business system.

Asynchronous Receive: Receives the Response message from the asynchronous business system.

Synchronous Send: Sends the Response message from the asynchronous business system synchronously to the synchronous business system and closes the sync/async bridge. The message type of the message to be sent must correspond to that of the reply message from the synchronous interface in the opening receive step. In the send step, enter the name of the receive step that opened the sync/async bridge (in this example SyncReceive).

Opening Receive step:

You can only use one receive step to open a sync/async bridge for each integration process. The receive step to open an s/a bridge must start the integration process. There must be no other receive steps to start the integration process.

You can insert the receive step for opening a sync/async bridge in the following positions in an integration process:

Directly after the start marker

As the first step in a block if the block is the first step of the integration process and has the mode Standard

As the first step in a fork. If the fork already contains some starting receive steps, the Start Process indicator is automatically reset for these steps.

In the object area, define the container element that receives the synchronously sent message:

You must specify an asynchronous, abstract interface in the container element. The message must correspond to the request message of the synchronous interface used to receive the message.

Choose this container element for the property Message.

Set the Start Process indicator.

Choose Opens S/A Bridge for the property Mode.

Choose the synchronous interface to be used to receive the message.

SEND MESSAGE ASYNCHRONOUS

Asynchronous mode (default): the send step does not wait for a reply message from the receiver after it has sent the message. However, you can specify that the asynchronous send step must wait for a confirmation of receipt from the receiver, in the form of an acknowledgment. Prerequisite: The receiver (adapter, business system and so on) sends the corresponding acknowledgment.

None (default): Step is complete when the message has been successfully sent to the pipeline.

Transport Acknowledgement: step waits for the transport acknowledgment. This specifies that the message was received successfully.

Application Acknowledgement: The step waits for an application acknowledgment. This specifies that the message was processed successfully by the receiver application (for example, u2018postedu2019).

Receiver Determination

The message receiver can be a business system or another integration process. You have various options for the receiver determination:

Send Context (default): The send context is a freely definable string, which you specify in the send step. You query the send context in a condition in the receiver determination in the Integration Directory. You must specify the send context if you want to send messages from the same message interfaces to different receivers in different send steps.

Receiver list: You determine the list of receivers in a preceding receiver determination step. Next, from the properties of the send step, choose the container element that contains the receiver list. The send step itself does not call the receiver determination that is configured in the Integration Directory; instead it uses the receiver list.

Response message in reply to a previously received message: You specify the message that the send step is to send a response to. The receiver is determined from the message header of this message. In this case, the receiver determination that is configured in the Integration Directory is not called.

Activating Correlations

Send step within a block with a ParForEach: In a block with a ParForEach, the elements of a multiline container element are processed in parallel instances of the block at runtime. If a send step within the ParForEach sends a message, and a separate message is to be received for this message for each element of the multiline container element, then the send step can activate the corresponding correlation.

SEND MESSAGESYNCHRONOUS

In Synchronous mode, the send step waits for a reply message from the receiver after it has sent the request message. In a synchronous send step you specify the synchronous abstract interface for sending the request message and receiving the reply message. Furthermore, you specify the container element that the request message references and the container element in which the reply message is to be received. The container element type for the request message must be the same as the outbound message interface of the synchronous interface. The container element type used to receive the reply message must be the same as the inbound message interface of the synchronous interface.

In a synchronous send step you can define additional exceptions for application errors, provided the corresponding fault messages are defined in the synchronous interface. You can define an exception for each fault message. This exception is thrown when the corresponding fault message is received.

Activating Correlations

A synchronous send step waits for a reply message to be received. On receipt of this reply message, correlations can be activated to correlate additional messages.

SEND ACKNOWLEDGEMENT

In Acknowledgment mode, a send step can send a positive or a negative acknowledgment for a particular message:

You usually use a positive acknowledgement in a branch that defines the normal case. A negative acknowledgment on the other hand is usually used in an exception handler.

The system automatically determines the receiver of the acknowledgment from the header of message, for which the acknowledgment was sent.

SEND SYN/ASYN

Closing A Sync/Async Bridge

You can use a send step to close a sync/async bridge for communication between a synchronous and an asynchronous business system. The send step sends the response from the asynchronous business system to the synchronous business system.

There can only ever be one sync/async bridge in an integration process. Therefore, there can only be one send step that closes a sync/async bridge as well. The send step cannot be in a loop, block, or a fork.

In the send step, specify the receive step that opened the synch/async bridge. Also specify the message to be sent to the synchronous interface. This message must be of the same type as the response message from the synchronous interface that you specified in the opening receive step.

For details on Sync/Async-Bridging see Process Patterns section.

TRANSFORMATION STEP

You use a transformation step to do the following:

n:1 Transformation: Bundles multiple messages into one message, for example, individual purchase order items into one purchase order.

1:n Transformation: Splits a message into multiple messages, for example, a purchase order into the individual purchase order items.

1:1 Transformation: Converts a message into another message, for example, a message that is defined by interface A is converted to message that is defined by interface B.

Since no receiver information is available in the transformation step, there can be no value mapping within the transformation step. If the messages to be transformed give values in different formats, for example different date formats, you must first u2018normalizeu2019 the values before the messages can be processed in the process. To do so, define a message mapping with a corresponding value mapping.

Attachments for n:1 and 1:n Transformations

If the messages you want to bundle contain attachments, the system collects and appends them to the bundled message. The source system or source systems must ensure that the attachments each have a unique name. If they donu2019t, the most recently received attachment will overwrite any attachments with the same name.

If the message you want to split contains attachments, the system replicates them and appends them to all the messages once they have been split.

Excpetions

You can enter an exception to be triggered when a system error occurs (permanent error)

RECEIVER DETERMINATION

You use a receiver determination step to get a list of receivers for a subsequent send step. The receiver determination step calls the receiver determination that you configured in the Integration Directory and returns the receiver list.

In the receiver determination step, specify the send context and the multiline container element for the receiver list.

The send context is an arbitrary string. You query this context in a condition in the receiver determination in the Integration Directory. You must specify the send context if you want to send messages from the same interface to different receivers in different send steps.

SWITCH

You use a switch to define different processing branches for a process. The Otherwise processing branch is created automatically.

You define a condition for each processing branch. The condition is checked at runtime. The process is continued in the branch that is first to return the value true. If no branch returns the value true, then the process is continued in the Otherwise branch.

The system checks the conditions in the order that they are numbered. This corresponds to the following sequence:

Vertical layout: From top to bottom

Horizontal layout: From left to right

CONTAINER OPERATION ASSIN/APPEND VALUE

You use a container operation to set a value for a target container element at runtime. The target container element and the assigned value must have the same data type. Use the Expression Editor to specify the value.

Append: Appends a value to a multiline container element. For example, you can use this container operation to attach individual messages to multiline container elements when collecting messages.

Assign: Assigns a value to a single line or multi-line container element. This value overwrites the previous value. You can use this container operation to count a counter variable, for example.

You cannot change a message by using a container operation. To change a message, use a transformation step.

CONTROL

Cancel process

At runtime, the system terminates the current process instance, including all active steps, and sets the status for the process to logically deleted.

Can be used in exception branches, for example.

FORK

You use a fork when you want to continue a process in branches that are independent of each other, for example, to communicate with two systems that are independent of each other. The branches of the fork join in a union operator.

You can specify the required number of branches and then define whether the process must run through all branches, or just a particular number of branches. Furthermore, you can define an end condition for the fork.

As soon as a branch reaches the union operator at runtime, the system checks the following conditions in the specified order:

The process has run through the required number of branches

The specified end condition has returned true

The step is complete as soon as one of the conditions returns true.

LOOP

You use a loop to repeat the execution of steps within the loop. The loop continues to run while the end condition returns true (while loop).

To specify the end condition, use the condition editor.

WAIT

You use a wait step to incorporate a delay in a process. Usually, you use a delay to define when the next step in the process is to start. You can define a delay as either a point in time or a period of time.

At runtime, the step waits until the specified point in time is reached or the specified period of time has passed. The system then continues the process by proceeding with the next step.

cheers

reward points if found useful

[former_member556603]

Hi,

BPM Steps:

Purpose

You use step types to define the individual processing steps of an integration process. The individual steps are displayed in the editor area of the graphical process editor. You insert a step into the definition of an integration process by using Drag&Drop.

Very imp link all stpes plus explanation is available in this link.....

http://help.sap.com/saphelp_nw04/helpdata/en/62/dcef46dae42142911c8f14ca7a7c39/content.htm

Thanks,

Satya Kumar

[former_member537867]

Hi Ginger,

Follow the below links

check list for BPM https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/3bf550d4-0201-0010-b2ae-8569d193...

monitoring BPm https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/e7bc3a5a-0501-0010-1095-eb4...

/people/shabarish.vijayakumar/blog/2005/08/03/xpath-to-show-the-path-multiple-receivers

http://help.sap.com/saphelp_nw04/helpdata/en/3c/831620a4f1044dba38b370f77835cc/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/62/dcef46dae42142911c8f14ca7a7c39/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/de/766840bf0cbf49e10000000a1550b0/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/cb/15163ff8519a06e10000000a114084/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/08/16163ff8519a06e10000000a114084/content.htm

Many other examples can be found under the following link at help.sap.com

http://help.sap.com/saphelp_nw04/helpdata/en/14/80243b4a66ae0ce10000000a11402f/frameset.htm

And some weblogs

https://weblogs.sdn.sap.com/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken]

/people/siva.maranani/blog/2005/05/22/schedule-your-bpm *****

/people/krishna.moorthyp/blog/2005/06/09/walkthrough-with-bpm

/people/michal.krawczyk2/blog/2005/06/11/xi-how-to-retrieve-messageid-from-a-bpm

/people/arpit.seth/blog/2005/06/27/rfc-scenario-using-bpm--starter-kit

/people/sravya.talanki2/blog/2005/08/24/do-you-like-to-understand-147correlation148-in-xi

/people/michal.krawczyk2/blog/2005/09/04/xi-do-you-realy-enjoy-clicking-and-waiting-while-tracing-bpm-steps *****

/people/udo.martens/blog/2005/09/30/one-logical-system-name-for-serveral-bpm-acknowledgements *****

/people/sudharshan.aravamudan/blog/2005/12/01/illustration-of-multi-mapping-and-message-split-using-bpm-in-sap-exchange-infrastructure

/people/kannan.kailas/blog/2005/12/07/posting-multiple-idocs-with-acknowledgement

Also have a look at these seminars,

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/media/uuid/daea5871-0701-0010-12aa-c3a0c...

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/media/uuid/e8515171-0701-0010-be98-e37be...

You can use Block step inside BPM error handling....

see the below blogs....

/people/sravya.talanki2/blog/2006/11/22/error-handling-framework-xiout-of-the-box-episode-1

/people/sravya.talanki2/blog/2006/11/23/error-handling-framework-xiout-of-the-box-episode-2

Use of Synch - Asynch bridge in ccBPM /people/sriram.vasudevan3/blog/2005/01/11/demonstrating-use-of-synchronous-asynchronous-bridge-to-integrate-synchronous-and-asynchronous-systems-using-ccbpm-in-sap-xi

Use of Synch - Asynch bridge in ccBPM https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken]

without BPM /people/henrique.pinto/blog/2007/08/02/syncasync-scenarios-without-bpm

without BPM1 /people/venkataramanan.parameswaran/blog/2007/01/18/syncasync-communication-in-jms-adapter-without-bpm-sp19

IDOC BPM /people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm

multimapping without BPM /people/jin.shin/blog/2006/02/07/multi-mapping-without-bpm--yes-it146s-possible

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/806556ff-a0e4-2a10-3089-a3fb676e...

Regards,

Vinod.

[former_member194786]

Hi,

For understanding BPM, please go through this blog:

/people/krishna.moorthyp/blog/2005/06/09/walkthrough-with-bpm

And for the step types use this:

http://help.sap.com/saphelp_nw04/helpdata/en/14/80243b4a66ae0ce10000000a11402f/frameset.htm

Regards,

Sanjeev.

[Former Member]

Hi,

Reffer this

Regards

Seshagiri

[Former Member]

hi

BPM means Business process management

To deal with Multiple sender and receivers based on the conditions we could use BPM. Its one of the feature of BPM, but its not mandatory to go for BPM for each n every case. Its depends upon scnenario.

BPM steps are divided into two types:

1)message steps

2)flow steps

message steps are :

a)send step

b)receive step

c)receiver determination step

d)tranformation step

flow steps are:

a)control step

b)container operation

c)block step

d)wait step

e)fork step

f)switch step

g)undefined step

h)loop step

Check these

BPM:

/people/krishna.moorthyp/blog/2005/06/09/walkthrough-with-bpm - Walk through BPM BPM in XI https://www.sdn.sap.com/irj/sdn/wiki?path=/display/xi/integrationProcess%28ccBPM%29inXI&

BPM-1 /people/krishna.moorthyp/blog/2005/06/09/walkthrough-with-bpm

BPM-2 /people/krishna.moorthyp/blog/2006/04/08/reconciliation-of-messages-in-bpm

BPM-3 /people/arpit.seth/blog/2005/06/27/rfc-scenario-using-bpm--starter-kit

BPM-4 /people/michal.krawczyk2/blog/2005/06/11/xi-how-to-retrieve-messageid-from-a-bpm

Schedule BPM /people/siva.maranani/blog/2005/05/22/schedule-your-bpm

Use of Synch - Asynch bridge in ccBPM /people/sriram.vasudevan3/blog/2005/01/11/demonstrating-use-of-synchronous-asynchronous-bridge-to-integrate-synchronous-and-asynchronous-systems-using-ccbpm-in-sap-xi

Use of Synch - Asynch bridge in ccBPM https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken]

without BPM /people/henrique.pinto/blog/2007/08/02/syncasync-scenarios-without-bpm

without BPM1 /people/venkataramanan.parameswaran/blog/2007/01/18/syncasync-communication-in-jms-adapter-without-bpm-sp19

IDOC BPM /people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm

multimapping without BPM /people/jin.shin/blog/2006/02/07/multi-mapping-without-bpm--yes-it146s-possible

/people/jin.shin/blog/2006/02/07/multi-mapping-without-bpm--yes-it146s-possible---- Multi Map With out BPM

/people/narendra.jain/blog/2005/12/30/various-multi-mappings-and-optimizing-their-implementation-in-integration-processes-bpm-in-xi Various multi-mappings and Optimizing their Implementation in Integration Processes (BPM) in XI.

/people/sudharshan.aravamudan/blog/2005/12/01/illustration-of-multi-mapping-and-message-split-using-bpm-in-sap-exchange-infrastructure --- Illustration of Multi-Mapping and Message Split using BPM in SAP Exchange Infrastructure

/people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm (N:1 Mapping )

regards

chandra