https://www.journaldev.com/3633/hibernate-interview-questions-and-answers
Friday, August 10, 2018
Monday, March 19, 2018
Interviews questions wesb
Q. What is ESB?
An enterprise service bus (ESB) is software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.
Q. What is the functionality of Fan-in and Fan-out?
Fan-out:We can use the Fan Out primitive to fire the output terminal once (with the input message) or to fire the output terminal multiple times. You can use Fan Out in isolation or as part of a Fan Out and Fan In combination.
Fan-In: Fan In is always partnered with a Fan Out in the same flow and acts as a decision point for when to continue flow execution. It receives a number of messages until a decision point is reached, at which point the last message to be received is propagated to the output terminal. The Fan In primitive may only be used in combination with Fan Out.
Q. What are all the configurations required for JDBC Adapter implementation?
Data Source need to be created and need to configure with DB. If we have security, then need to created security authentication.
Q. Different between SDO and SMO?
SDO: Service Data Object is the representation of the variable or Object.
SMO: The SMO model is a pattern for using SDO Data Objects to represent messages
Q. Difference between Stop and fail?
Stop: Stops a particular path in the flow, without generating an exception.
Fail: Generates a failure in the flow.
Q. How can you change the runtime changes using mediation primitive?
We have future called Promotable properties in ESB. We can configure this future while development. Then we can make it changed at runtime without restarting the server it can be published.
Q. What are all the Primitives used in Mediation?
We have different types of primitives in mediation.
Message Filter
1. Type Filter
2. Endpoint Lookup
3. Service Invoke
4. Fan-out
5. Fan-in
6. XSLT
7. BO Map
8. Message Element Setter
9. DB lookup
10. Data Handler
11. Custom Mediation
12. Header Setters
13. Message Logger
14. Even Emitter
15. Stop
16. Fail
17. Sub Flow
Q. Difference between BO Map and XSLT?
Both are used for manipulate and transfer the message.
Use XSLT whenUse BO Maps whenYou have an existing stylesheet or want to use custom XSLT in the map. You have an existing BO Map or submap.You want to use XPath expressions inside the map. You want to use the relationship service (particularly dynamic relationships).
You want to use Java snippets that use the DOM API to access or update data.
You want to use Java snippets that use the BO API (SDO API) to access or update data.You want to use built-in XPath or EXSLT functions to access or modify data. You want to order the completion sequence for the transforms.You want to combine contents from more than one array (repeating element). BO Maps can be faster when used with WebSphere® Adapters, because the BO Maps work directly with the SDO API.
Performance with XSLT or BO Maps depends on a number of factors including:
1. An XSLT map is fastest when processing web services messages and the incoming data is unmodified between the entrance to the mediation flow and the XSLT primitive.
2. A BO map can be faster when the message content has already been accessed in the mediation flow.
Q. What is SMO? And wt it contains?
The SMO model is a pattern for using SDO Data Objects to represent messages. The SMO contains a representation of the following groups of data:
1. The business payload of the message. The payload is the application data exchanged between service endpoints.
2. Header information associated with the message. For example, Java Message Service (JMS) headers if a message have been conveyed using the JMS API.
3. Context information (data other than the message payload).
Q. What are Shared, Transient and Correlation Context?
1. Shared Context: Context is a temporary area which is created along with Service Message Object (SMO) in the Mediation Flows. Shared Context is a type of context which is present in the SMO. Shared Context is mainly used when we are using Aggregation process where we need to Iterate the BO for Certain times. Shared Context maintains Aggregation data between Aggregation (FanOut and FanIn) primitives. The Content (data) which is present in the shared context BO does not persist across Request and Response flows i.e The Data in the Shared Context which is used in Request flow can not be used again in Response flow.
2. Transient Context: Used for passing values between Mediation primitives within the current flow — either the request flow or the responses flow. The transient context cannot link requests and responses and hence cannot be used across.
Used when you want to save an input message before a service invokes call(within a request or response flow). After the services invoke call, the next primitive can create another message by combining the service invoke response and the original message stored in the transient context.
3. Correlation Context: Used when Mediation primitives want to pass values from the request flow to the response flow.
Used to pass values from the request message onto the response.
Q. Difference between Callout and Service Invoke?
Service Invoke: The Service Invoke primitive is used to make a service request in either a request or response mediation flow. The service may be Request/Response or One-Way. Multiple instances of the Service Invoke primitive are permitted in a flow, allowing a series of service invocations to be performed.
Callout: The Callout receives the message and calls the requested service and operation. There is a Callout node for each connected target operation in the mediation flow.
1. If the call is successful, the Callout Response node in the response flow receives the response message.
2. If the call is unsuccessful, the Callout can be set to retry service invocations depending on the type of fault received.
Q. How can you implement loop in mediation?
By using Fan-in and Fan-out primitive.
Q. What is the functionality of Fan-in and Fan-out?
Fan-out:We can use the Fan Out primitive to fire the output terminal once (with the input message) or to fire the output terminal multiple times. You can use Fan Out in isolation or as part of a Fan Out and Fan In combination.
Fan-In: Fan In is always partnered with a Fan Out in the same flow and acts as a decision point for when to continue flow execution. It receives a number of messages until a decision point is reached, at which point the last message to be received is propagated to the output terminal. The Fan In primitive may only be used in combination with Fan Out.
- Migration to WebSphere ESB
In this release, you can migrate your installed applications and profile configurations from prior versions of IBM WebSphere ESB to WebSphere ESB version 7.0 using version-to-version migration tools. Version-to-version migration requires that you install the new version of the product alongside the older product, then run migration tools to migrate the existing applications and configurations to the new product. You cannot use updates (in-place upgrades) to migrate from previous releases to WebSphere ESB version 7.0.
Jdbc adapter's
The adapter supports integration of databases that are accessible through the JDBC application programming interface (API) with applications running on IBM® Business Process Manager or WebSphere® Enterprise Service Bus. The adapter provides outbound and inbound processing under the Java 2 Platform, Enterprise Edition (J2EE) Connector Architecture (JCA) and integrates with Service Component Architecture (SCA) components.
Outbound processing enables an application to access or modify data in a database. The adapter converts a request from the application to an outbound operation, which it runs to create, retrieve, update, or delete data in the database or to run a database program stored in the database. Processing these requests results in the creation, retrieval, update, or deletion of rows in the corresponding database tables. The adapter also enables you to run stored procedures or stored functions that are defined in the database, and to run user-defined SELECT, INSERT, UPDATE, and DELETE statements. You can use the adapter to integrate multiple applications with the same database.
Figure 1 presents an overview of the flow of outbound processing.
An application running in IBM Business Process Manager or WebSphere Enterprise Service Businvokes a service in an outbound module, which sends a request to the adapter to process one or more business objects. The adapter uses the JDBC API to connect to the database server, which accesses the tables and other objects in the database.
Figure 1. Processing outbound requests
Inbound processing enables an application to receive notification when objects in the database are changed. For example, an application can be notified when rows are created, updated, or deleted in selected database tables.
Figure 2 presents an overview of the flow of inbound processing.
A database application changes tables in the database. The change causes a trigger, or another automated mechanism, to update the event store with information about the change. Periodically, the adapter polls the event store, retrieves, and processes events, and then delivers them to the export of a module that is part of an application that runs in IBM Business Process Manager or WebSphere Enterprise Service Bus.
Figure 2. Processing inbound events
The adapter can process events in one of the following ways:
Standard event processing, using an event store that is populated by the database application
Custom event processing, using a user-defined database query
During standard event processing, when data is changed in the tables in the database, appropriate events are inserted into a database table called an event store, along with relevant information, such as key values. To capture the changed data, you can place triggers on the respective tables, or use other methods such as Oracle Change Data Capture, which is provided for Oracle databases. The adapter polls the event store and retrieves a batch of events. The events can be filtered by business object type and time stamp and connector ID. The adapter uses each event to construct a business graph or business object that contains the business objects changed by that event. The business object or business graph is then dispatched to the exports that are configured to receive the specific business object.
During custom event processing, the adapter runs a query that was specified by the user as a standard SQL statement, a stored procedure, or a stored function. Any of these actions returns a result set for data returned by the query. Each row of the result set corresponds to a row in the event store. The adapter constructs a business object for each event and delivers it to the exports (also called endpoints) that are configured for (or have subscribed to) the specific business object.
For both standard and custom event processing, you can specify how often the adapter polls for events and how many events it retrieves each polling period.
When an application component needs to query the existence of a record in the database or retrieve or modify data in the database, the adapter acts as the connector between the application component and the database. The adapter provides a set of standard outbound operations, which process either after-image or delta style business objects. The adapter also supports both local and XA (distributed) transactions for outbound processing.
The adapter supports inbound event management with event delivery. Events are processed from an event store that is populated either by the database application or from the result of custom queries that you provide. You control how often the adapter polls for events and how many records are delivered to the export at one time.
A business object is a structure that consists of data, the action to be performed on the data, and additional instructions, if any, for processing the data. IBM WebSphere Adapter for JDBC uses business objects to represent tables and views in the database as well as the results of database queries, stored procedures, and stored functions. Business objects can also create a hierarchy of objects from your database and group unrelated tables. Your component communicates with the adapter using business objects.
Tables, views, and synonyms overview
Databases provide the common database objects that include tables, views, and synonyms.
A stored procedure can be a business object that your module runs with the Execute operation. It can run in place of the standard SQL for an operation on any business object, or it can perform additional actions before or after performing an operation.
Stored procedure business object overview
You can create a stored procedure business object that corresponds to a stored procedure or stored function in the database. You can then use the Execute operation to run the stored procedure against the data in the database.
Stored procedures used in place of or in addition to operations
You can specify that the adapter use a stored procedure in the database in place of, before, or after the SQL statements that the adapter uses to perform an operation. Each business object can have a different set of stored procedures used with each operation.
Some databases support stored functions in addition to stored procedures. Stored functions are like stored procedures except that they always return a value. The adapter supports them in a similar manner.
Query business object overview
Query business objects run a user-defined SELECT statement against the database and return the matching records in business objects.
Batch SQL business object overview
A batch SQL business object runs one or more user-defined INSERT, UPDATE, and DELETE statements and returns the status of the statements.
Use the external service wizard in IBM Integration Designer to discover objects in a database; to generate batch SQL, query, and wrapper business objects; and to generate business objects from selected database objects. The wizard also generates the module and the service artifacts that enable the adapter to run as a Service Component Architecture (SCA) component.
The adapter creates log and trace files that can be viewed with the Log and Trace Analyzer.
The adapter supports business faults, which are exceptions that are anticipated and declared in the outbound service description, or import. Business faults occur at predictable points in a business process, and are caused by a business rule violation or a constraint violation.
Parent topic:Overview of IBM WebSphere Adapter for JDBC
Related tasks
Setting deployment properties and generating the service
Setting deployment properties and generating the service
Related reference
(C) Copyright IBM Corporation 2005, 2011. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)
Saturday, January 27, 2018
Performance Tuning
1) How you are integrating with MA systems (Sync or Async) ?
if it’s a Sync call, increase global transaction timeout , by default it will be 180 sec.
or
if it’s Async - you need to check your design that it’s really required to go with Async , as you said your transaction is waiting for long time. In ESB's you can set callout time.
At the moment, WPS making Sync calls to the backend system, and global transaction timeout in WPS server is 120 secs.
2) Have you guys did performance testing ?
No, there was no performance testing done on WPS server.
3) Connection pool size 10 is very low. Min 50 is recommended.
Yes, we are looking for the recommendation and can be considered. Can you please let us know , by increasing the connection pool size will there be any other issues like performance that may arise. As mentioned, WPS server is a stand-alone at the moment.
4) what is the connection pool type
Recommended to use non-XA data source if your data is not critical and you don't have auto roll back mechanism.
By default it was enabled in the WPS server, and we are logging each and every transaction in WPS server.
5) you need to increase maximum heap size to get rid of Out of Memory exceptions . 768 mb is recommended you can increase to 2 GB if you have enough RAM.
Currently we have minimum heap size as 4 GB and maximum heap size as 10 GB. And our current RAM is 42 GB and looking for some recommendation on this.
6) Ask WPS admin to increase thread pool size. It can also be the reason for hung threads/out of memory exception.
Web Container thread pool size is minimum 50 and maximum 50 and MQ thread pool size is minimum is 1 and maximum is 40. But we are looking for the recommendation here to increase the thread pool size.
Subscribe to:
Posts (Atom)