1. Write a function called getMostFollowers, which accepts a variable number of arguments. You should then make an AJAX call to the Github User API (https://developer.github.com/v3/users/#get-a-single-user) to get the name and number of followers of each argument. The function should return a promise, which when resolved, returns a string which displays the username who has the most followers.
Hint - Try to use Promise.all to solve this and remember that the jQuery AJAX methods ($.getJSON, $.ajax, etc.) return a promise.
getMostFollowers('elie','tigarcia','colt').then(function(data){ console.log(data) }); "Colt has the most followers with 424"
2. Write a function called starWarsString, which accepts a number. You should then make an AJAX call to the Star Wars API (https://swapi.co/ ) to search for a specific character by the number passed to the function. Your function should return a promise that when resolved will console.log the name of the character.
starWarsString(1).then(function(data){ console.log(data) }) "Luke Skywalker"
Bonus 1 - Using the data from the previous AJAX call above, make another AJAX request to get the first film that character is featured in and return a promise that when resolved will console.log the name of the character and the film they are featured in
starWarsString(1).then(function(data){ console.log(data) }) "Luke Skywalker is featured in The Empire Strikes Back, directed by Irvin Kershner"
Bonus 2 - Using the data from Bonus 1 - make another AJAX call to get the information about the first planet that the film contains. Your function should return a promise that when resolved will console.log the name of the character and the film they are featured in and the name of the planet.
starWarsString(1).then(function(data){ console.log(data) }) "Luke Skywalker is featured in The Empire Strikes Back, directed by Irvin Kershner and it takes place on Hoth"


|
After two months of rising tensions between rival warlords across much of Afghanistan, Gardez, a strategic city 130 kilometers south of Kabul has erupted in heavy fighting that continued Thursday with bursts of mortar, rocket and rifle fire, and smoke from exploding ammunition.
|
|
An explosive eight-year investigation of corruption at the French oil giant Elf-Aquitaine is expected to produce a last roar next week, as magistrates file a final report naming roughly 40 executives, politicians and intermediaries as parts of a pervasive network that allegedly bilked nearly 3 billion francs from Elf in the early 1990s.
|
|
The European Union's senior legal officer declared Thursday that "open skies" aviation agreements between several EU governments and the United States are illegal, opening the way to an eventual revolution in European and trans-Atlantic air transport.
|
|
International financial leaders are growing increasingly concerned about Japan's huge debt and dire economic condition, even to the point of suggesting that further deterioration could trigger global financial instability.
|
|
A new screening test for colon cancer, based on detecting a gene that is disrupted very early in the course of the disease, could prevent many thousands of deaths each year, researchers reported Thursday.
|


By default, buttons are already injected with the ripple effect.
ripple|noripple|ripple-color={color}
{color} can be a css color name, material color(see colors), hex, or rgb[a] values.
{color}


{% import 'headers.html' as headers %} {% import 'footers.html' as footers %} {% import 'algo.html' as algo %}
This article shows quick method for solving equations in form \(a^b \equiv x \pmod m\) and how to use it in order to find \(k\)-th element of a linear recursive equation with constant coefficients.
Suppose You have three numbers: \(0 < a, b, m ≤ 10^9+7\), and are asked to find \(x: a^b \equiv x \pmod m\). To solve this problem with algorithm different than brute force (multiply \(a\ b\) times modulo \(m\) - complexity \(O(b)\) - it can be assumed, that multiplication modulo \(m\) works in \(O(1)\)), one can use binary exponentiation.
\(a^b\) can be shown as: $$ a^b=a^{2 \lfloor \frac{b}{2} \rfloor +b\ mod\ 2}=a^{2 \lfloor \frac{b}{2} \rfloor } *a^{b\ mod\ 2} = (a^2)^{\lfloor \frac{b}{2} \rfloor } *a^{b\ mod\ 2} $$ And so, \(a^b\ mod\ m=(((a^2)^{\lfloor \frac{b}{2} \rfloor}\ mod\ m)*(a^{b\ mod\ 2}\ mod\ m))\ mod\ m\). Value of \(b\ mod\ 2\) is either \(0\) or \(1\) - and so, calculating \(a^{b\ mod\ 2}\ mod\ m\) takes \(O(1)\) time complexity. Calculating \(a^2\ mod\ m\) also takes \(O(1)\) time complexity, and repeating calculations recursively until \(b > 0\) takes at most \(log_2(b)\) iterations. Overall complexity of the algorithm is therefore \(O(log(b))\). One can keep result \(res=1\) at the beginning of the algorithm and update values in each iteration: $$ res = res*a^{b\ mod\ 2}\ mod\ m $$ $$ b = \lfloor \frac{b}{2} \rfloor $$ $$ a = (a*a)\ mod\ m $$ Until \(b=0\) - this makes process iterative.
{{ algo.neo_algorithm(1, 'Binary Exponentiation', 'Input format: three numbers \(a, b, m\), such that \(x=a^b \pmod m\) has to be found.
\(a, b, m\)
This animation shows, why method is called binary exponentiation: if \(b\) is shown as \(b=2^{i_1}+2^{i_2}+...+2^{i_k}\), where \(\forall_{w,v} i_w \neq i_v\), then \(res=a^{2^{i_1}}*a^{2^{i_2}}*...*a^{2^{i_k}}\).
The method above also allows multiplication modulo \(m\), but \(res=0\) on the beginning - for \(0\) is neutral element of addition. One can utilize this method to raise matrices to power, because matrix multiplication is associative (i.e \((A*B)*C=A*(B*C)\)). This allows raising square matrices to \(n\)-th power within \(O(k^3log(n))\) time complexity, where \(k\) is matrix size.
Suppose a recursive sequence is given in form: \(f_n=c_1f_{n-1}+c_2f_{n-2}+...+c_kf_{n-k}+c_0\) And thine purpose is to find \(f_n\ mod\ m\) with constraints: \(c_i, m, n \le 10^9, k \le 100\), where \(c_i, f_i\) for \(i \le k\) are given (also, \(f_i \le 10^9\) for \(i \le k\)).
Standard brute-force dp solution would solve this problem in \(O(nk)\) - by calculating \(n\)-th element with previous \(k\) elements kept in memory, plugged into equation.
But, there is certain property of recursive sequences, that can be utilized. Namely: $$ \begin{bmatrix} c_1 & c_2 & c_3 & \cdots & c_{k-1} & c_k & c_0\\ 1 & 0 & 0 & \cdots & 0 & 0 & 0\\ 0 & 1 & 0 & \cdots & 0 & 0 & 0\\ 0 & 0 & 1 & \cdots & 0 & 0 & 0\\ \vdots & \vdots & \vdots & \ddots & \vdots & \vdots & \vdots\\ 0 & 0 & 0 & \cdots & 1 & 0 & 0\\ 0 & 0 & 0 & \cdots & 0 & 0 & 1\\ \end{bmatrix} \begin{bmatrix} f_{n-1} \\ f_{n-2} \\ f_{n-3} \\ f_{n-4} \\ \vdots \\ f_{n-k} \\ 1\\ \end{bmatrix} = \begin{bmatrix} c_1f_{n-1}+c_2f_{n-2}+..+c_kf_{n-k}+c_0*1 \\ 1f_{n-1}+0f_{n-2}+...+0f_{n-k}+0*1 \\ 0f_{n-1}+1f_{n-2}+...+0f_{n-k}+0*1 \\ 0f_{n-1}+...+1f_{n-3}+...+0f_{n-k}+0*1 \\ \vdots \\ 0f_{n-1}+...+1f_{n-k+1}+0f_{n-k}+0*1 \\ 0f_{n-1}+0f_{n-2}+...+0f_{n-k}+1*1\\ \end{bmatrix} = \begin{bmatrix} f_n \\ f_{n-1} \\ f_{n-2} \\ f_{n-3} \\ \vdots \\ f_{n-k+1} \\ 1\\ \end{bmatrix} $$ So, such matrix as above transforms vector having \(k\) subsequent elements ending on \(f_n\) to vector having \(k\) subsequent elements ending on \(f_{n+1}\). What follows, multiplying vector by such matrix \(v\) times would result in a vector ending on \(f_{n+v}\). $$ \begin{bmatrix} c_1 & c_2 & c_3 & \cdots & c_{k-1} & c_k & c_0\\ 1 & 0 & 0 & \cdots & 0 & 0 & 0\\ 0 & 1 & 0 & \cdots & 0 & 0 & 0\\ 0 & 0 & 1 & \cdots & 0 & 0 & 0\\ \vdots & \vdots & \vdots & \ddots & \vdots & \vdots & \vdots\\ 0 & 0 & 0 & \cdots & 1 & 0 & 0\\ 0 & 0 & 0 & \cdots & 0 & 0 & 1\\ \end{bmatrix}^v \begin{bmatrix} f_n \\ f_{n-1} \\ f_{n-2} \\ f_{n-3} \\ \vdots \\ f_{n-k+1} \\ 1\\ \end{bmatrix} = \begin{bmatrix} f_{n+v} \\ f_{n+v-1} \\ f_{n+v-2} \\ f_{n+v-3} \\ \vdots \\ f_{n+v-k+1} \\ 1\\ \end{bmatrix} $$ And so, this allows computing value of a recursive sequence in \(O(k^3log(n))\). Notably, one can use this trick also to solve recurrences using index of a sequence, power of some value, and so on as long as one can find transformation matrix from a vector to next vector of elements; sometimes one can logarithm a sequence to obtain feasible sequence.
Problems involving binary exponentiation can be found literally everywhere, most interesting ones usually involve recursive sequence trick or number of paths in a graph of certain length.
Anniversary,
Product Oriented Recurrence,
GukiZ and Binary Operations,


|
|||||||
SAP Java Connector 3.0 |
|||||||
| Release notes 3.0.16 | |||||||
| Bugfix for IOException when using bgRFC units | |||||||
A java.io.IOException with detail message "CS error: -81" was thrown at invoking
the method JCoFunctionUnit.commit(JCoDestination) or JCoRequestUnit.commit(JCoDestination) .
The IOException only occurred after 498 bgRFC units had already been processed successfully.
| |||||||
| Bugfix for using a different repository user in conjunction with SNC | |||||||
When using the SNC Single Sign On (SSO) mechanism, a specifically configured different repository user and password
via the properties jco.destination.repository.user and jco.destination.repository.passwd
were ignored and the application user identity of the respective JCoDestination configuration was
erroneously also used for repository RFC meta data queries to the AS ABAP back-end.
| |||||||
| Bugfix for working with JCoRepository instances in roundtrip optimization mode | |||||||
A java.lang.NullPointerException might have occurred if using a JCoRepository instance in
roundtrip optimization mode (i.e. the middleware property jco.use_repository_roundtrip_optimization
was set to 1 at its creation time). The NullPointerException was either thrown
when trying to execute a JCoFunction object which has been created by such a repository instance or
even earlier when querying the meta data for a JCoFunction , JCoFunctionTemplate or a
JCoRecordMetaData object from an AS ABAP back-end system. Only certain complex data structures and
table parameter definitions were affected by this bug.
| |||||||
| Bugfix for starting a SAP GUI via a NAT router | |||||||
When opening an RFC connection with using a SAP GUI by specifying the optional logon parameter
jco.client.use_sapgui to be of value 1 or 2 , the SAP GUI failed to start
and could not be attached to the new RFC connection if some network address translation (NAT) was done on the route
between the JCo program and the target AS ABAP system.
| |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Release notes 3.0.15 | |||||||
| Support for the platform Linux on IBM Power PC 64-bit LE | |||||||
|
Linux operating systems running on IBM Power PC 64-bit Little Endian processors are supported now. Appropriate JCo
SDK and runtime installation archives for this new platform are available for download as of JCo 3.0.15. Please see SAP note 1077727 for a complete and detailed list of supported platforms and Java runtime environments. | |||||||
| Bugfix in method JCoAttributes.getSystemID() and JCoServer multiple repository mapping | |||||||
The method JCoAttributes.getSystemID() which was called on an RFC attributes object retrieved by
invoking JCoServerContextInfo.getConnectionAttributes() in an RFC server scenario might have returned
a wrong system ID (SID) if the relevant JCoServer was used in a mixed scenario with receiving
RFC requests from both: SAP ABAP systems and external non-ABAP RFC client programs. As a consequence this then also
resulted in the wrong JCoRepository instance being used when the JCoServer was configured
to use the multiple repositories feature (configured with property jco.server.repository_map ).
| |||||||
| Bugfix in method JCoAttributes.getSystemNumber() | |||||||
The method JCoAttributes.getSystemNumber() might have returned a wrong system number if the
destination that provided the JCoAttributes instance was configured for logon load balancing
and was running in a stateful context.
| |||||||
| Bugfixes in method JCoRepository.load() | |||||||
Nested deep structures and also tables with a single field vector of a predefined datatype were not correctly loaded
into a JCoRepository instance. The respectively constructed and cached JCo meta data objects contained
internal errors so that their usage in a remote function call lead to a java.lang.ArrayIndexOutOfBoundsException
or a java.lang.NullPointerException .
| |||||||
| Bugfixes in method JCoRepository.save() | |||||||
The cached meta data of a JCoRepository instance was not completely stored at calling method
JCoRepository.save() . Some nested deep structure meta data objects could have been skipped and were
not serialized into the JSON format stream. Hence, a JCoRepository loaded from this serialized JSON
data was lacking required meta data and needed to query this meta data again via remote function calls.Furthermore the nesting type information for complex deep structures and the ABAP type information for structure type table parameters were incorrectly stored. Although these values could have been wrong, this particular error did not have a negative impact at runtime. | |||||||
| Bugfix for communication with R/3 systems of release 4.0A and 4.0B | |||||||
RFC communication with legacy R/3 systems of release 4.0A and 4.0B did not work anymore and an ABAP runtime error
of type CALL_FUNCTION_WRONG_VERSION occurred when trying to execute a remote function module in such
an R/3 system. At the JCo RFC client side a JCoException with error group JCO_ERROR_SYSTEM_FAILURE
and error message text "RFC log version &1 not supported" was thrown.Note: This bug was present in JCo release 3.0.14 only. | |||||||
| Enhancement with automatically obfuscating passwords | |||||||
The default file storage based DestinationDataProvider of the JCo runtime has been enhanced with a new
feature for automatically obfuscating passwords in its managed <DestinationName>.jcoDestination
property files, provided that the JCo process has write permission for the respective directory.Caution: Although obfuscated passwords provide better security than plain text passwords, they must be regarded as being generally insecure nevertheless. For security reasons it is still strongly recommended to register an own DestinationDataProvider instance in productive environments that stores destination
configurations in a secure persistent layer and uses a proven secure encryption algorithm, especially for the user
logon credentials.
| |||||||
| New APIs | |||||||
The following new enum constants have been added and are available for general use:
See the API documentation for details.
| |||||||
| Release notes 3.0.14 | |||||||
| Bugfix in internal connection pool management for recovering from pool exhaustions | |||||||
Sometimes an internally managed connection pool did not recover from a pool exhaustion situation and permanently
threw a JCoException with error group JCO_ERROR_RESOURCE when trying to execute a remote
function module. This error situation could only have occurred if the respectively used destination was not
configured with the property jco.destination.max_get_client_time set to 0 and furthermore
regular pool exhaustion exceptions for this destination already occurred before.
| |||||||
| Enhancement for improving the network stability during long running RFC client calls | |||||||
JCo now sends CPIC keep alive pings in regular time intervals to the SAP gateway during long running RFC client
calls in order to prevent firewalls and other network devices from closing the used underlying TCP/IP socket after
some low level network connection idle timeout, although the respective RFC call is still being executed and
processed at the target AS ABAP back-end system. Additionally, this new CPIC keep alive ping feature also helps
with promptly detecting network errors and the loss of the RFC communication partner, so that an appropriate
JCoException with error group JCO_ERROR_COMMUNICATION can be thrown in such cases.
| |||||||
| Bugfix for native crash in message server service layer | |||||||
|
A native crash could have occurred when doing a load balanced logon via the SAP message server. Please see SAP note 2079142 for further details. | |||||||
| Bugfix for usage of the RFC protocol's basXML serialization with NetWeaver AS ABAP 7.02 (7.0 EhP 2) systems | |||||||
The RFC protocol's basXML serialization was not considered and not used when communicating with an AS ABAP system
of release 7.02. If a function module is flagged to support basXML in an AS ABAP system release 7.02, JCo is now
using this flag in an associated JCoRepository for the queried JCoFunctionTemplate from
that system. Furthermore, the runtime is now adhering the flag when communicating with 7.02 AS ABAP systems, thus
improving performance when exchanging large data in parameters belonging to an import, export, or changing
parameter list.
| |||||||
| Bugfix for querying meta data from a JCoRepository in roundtrip optimization mode | |||||||
A JCoRepository instance in roundtrip optimization mode (i.e. the middleware property
jco.use_repository_roundtrip_optimization was set to 1 at its creation time) could have
returned incomplete meta data for nested structures, e.g. if a structure contains nested structured elements like
tables only. As the meta data was not initialized completely, the JCoStructure instances being created
from it did not contain the nested JCoTable instances.At runtime this could have led to a NullPointerException being thrown with a call stack as follows:
java.lang.NullPointerException: while trying to invoke the method com.sap.conn.jco.rt.DefaultTable.clear() of a null object returned from com.sap.conn.jco.rt.AbstractRecord.getTable(int) at com.sap.conn.jco.rt.AbstractRecord.clear() at com.sap.conn.jco.rt.XRfcParser.<init>() at com.sap.conn.jco.rt.ComplexParameter.receiveXmlDataStarted() at com.sap.conn.rfc.engine.RfcImp.receiveXMLData() at com.sap.conn.rfc.engine.RfcGet.ab_rfcget() at com.sap.conn.rfc.engine.RfcRcv.ab_rfcreceive() at com.sap.conn.rfc.engine.RfcIoOpenCntl.RfcReceive() at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcClient.execute() ... | |||||||
| New APIs | |||||||
The following new API and constant have been added and are available for general use:
See the API documentation for details.
| |||||||
| Release notes 3.0.13 | |||||||
| Bugfix for native crash in JCoServer communication with SNC | |||||||
|
A native crash could have occurred when receiving an RFC request from ABAP to Java that was
secured with SNC (Secure Network Communication). Please see SAP note 2156181 for further details. | |||||||
| Enhancement with invalidating the internal DNS cache | |||||||
|
IP addresses, resolved host names, network services and resolved port numbers from the DNS (Domain Name System)
are internally cached by JCo in order to speed up the network performance. However, this behavior prevents to
set up DNS failover or DNS load balancing scenarios. And if the network configuration is changed, a restart of
the whole JCo process is required in order to clear the local DNS cache and to work with the changed TCP/IP
configuration again. So the JCo has been enhanced and its internal local DNS cache can now be configured to invalidate and remove the DNS cache contents in regular time intervals. Two new JCo properties are now available for this: jco.ni.dnscache.ttl and jco.ni.dnscache.negative.ttl . These properties can be set as
JVM startup parameters by using the -D JVM option and can also be modified during runtime via
API call. The properties define the time to live for DNS cache entries in seconds.Please see the API documentation at method JCo.setProperty(String key, String value) for further
details.
| |||||||
| Performance improvement with handling DATE and TIME fields | |||||||
The performance in multi-threaded usage scenarios with handling numerous DATE and TIME
fields has been improved significantly.
| |||||||
| Release notes 3.0.12 | |||||||
| Bugfix for hanging JCoServer connections | |||||||
If an RFC request was immediately sent to a just registered JCoServer RFC connection, this newly
registered RFC server connection could have get into an unrecoverable hanging situation before the incoming
RFC request could have been dispatched and processed. At the communication partner side the RFC request did
not return and the active RFC connection kept hanging in status 'connected'.Note: This bug was present since JCo release 3.0.10 and was not completely fixed with JCo release 3.0.11. | |||||||
| Improvement for detecting network errors at sending CPIC pings | |||||||
Network errors were not detected when sending CPIC keep alive pings for registered JCoServer
connections. The mechanism was only useful for avoiding that TCP/IP connections are getting closed by
some network hardware, routers, firewalls or other proxies because of network connection idle timeouts.
Now also network errors will be recognized by this mechanism so that hanging JCoServer
connections can be avoided in case of detectable network errors as well. Please see SAP note
2079312 for further details.
| |||||||
| Bugfix for missing Unicode metadata in JCoRepository | |||||||
If the initialization of a new JCoRepository object failed for whatever reason, e.g. because an
RFC_ERROR_COMMUNICATION occurred at opening the first RFC connection to the associated AS ABAP
system, this JCoRepository instance did never query and store Unicode RFC metadata in its cache.
This resulted in a follow-up error with an internal java.lang.ArrayIndexOutOfBoundsException to
be thrown when executing a remote function call due to the missing metadata.
| |||||||
| Bugfix in JCoRepository instance management | |||||||
Under special circumstances a JCoRepository instance was sometimes dropped and removed from the
JCo runtime's central repository storage when a related destination configuration was deleted from the
JCoDestinationManager . In this case all the RFC metadata that was cached within the dropped
JCoRepository instance was lost and - if needed again - had to be queried from the associated
SAP system once again, which usually is a very time consuming task.
| |||||||
| Bugfix in method JCoAttributes.getPartnerHost() | |||||||
The method JCoAttributes.getPartnerHost() might have returned a wrong partner host name if the
destination that provided the JCoAttributes instance was configured for logon load balancing
and was running in a stateful context.
| |||||||
| Bugfix for configuration exceptions in extern-to-extern client communication scenarios | |||||||
When using a destination instance that targets an external RFC server program, a call to method JCoFunction.execute(destination, ...)
always threw a JCoException with error group JCO_ERROR_CONFIGURATION , if the
destination was not configured with a valid 'jco.destination.repository_destination' property.
However, no repository is needed at this time for executing a remote function call in an external RFC server
program. Hence, throwing a JCoException with error group JCO_ERROR_CONFIGURATION
was not justified in this calling context.
| |||||||
| Support of stateful extern-to-extern RFC client communication with started RFC server programs | |||||||
Support for stateful extern-to-extern RFC client communication with started RFC server programs has been
added. It is now possible to use a stateful call context with JCoContext.begin(destination) and
JCoContext.end(destination) to destinations that target started external RFC server programs.Note: Stateful extern-to-extern RFC client communication with registered RFC server programs still remains unsupported. | |||||||
| New APIs | |||||||
The following new constant has been added and is available for general use:
See the API documentation for details.
| |||||||
| Release notes 3.0.11 | |||||||
| Bugfix for lost scope types when using JCoCustomDestinations | |||||||
Scope types were lost when using JCoCustomDestination instances. Remote function calls via a
JCoCustomDestination instance were always executed within the default scope type context. In
case that the current JCo context was stateful, this resulted in the same RFC connection being used for all
JCoCustomDestination instances and therefore possibly destroyed the integrity of an LUW
(Logical Unit of Work).Note: This bug was present in JCo release 3.0.10 only. | |||||||
| Bugfix for hanging JCoServer connections | |||||||
If an RFC request was immediately sent to a just registered JCoServer RFC connection, this newly
registered RFC server connection could have get into an unrecoverable hanging situation before the incoming
RFC request could have been dispatched and processed. At the communication partner side the RFC request did
not return and the active RFC connection kept hanging in status 'connected'.Note: This bug was present in JCo release 3.0.10 only. | |||||||
| Bugfix in connection pool management at program termination | |||||||
When shutting down the JCo application program, pooled idle and still open RFC connections were not closed
properly before the application program terminates. This resulted in these pooled RFC connections being
interrupted instead with getting CPIC error messages"Connection to partner '<host>:<port>' broken / Connection reset by peer"
at the RFC communication partner side.
| |||||||
| Bugfix in method JCoRepository.save() | |||||||
A java.lang.NullPointerException was thrown when saving a JCoRepository instance
which contained a remote function module template with an empty import parameter list.
| |||||||
| Bugfix in method JCoRepository.load() | |||||||
The meta data information that specifies if a parameter is an optional parameter or not was lost after loading
a JCoRepository instance from a Java I/O character stream. Calling method
JCoListMetaData.isOptional(<name|index>) on any parameter meta data that was loaded by a
JCoRepository always returned false in this case.
| |||||||
| Bugfix in error handling when logging on to non-Unicode ABAP systems | |||||||
A java.lang.NullPointerException was always thrown when trying to logon to a non-Unicode ABAP
system with using one of the new logon languages that are available in Unicode SAP systems only. Now an
appropriate JCoException with error group RFC_ERROR_LOGON_FAILURE will be thrown in
such a scenario instead.
| |||||||
| Enhancement with transferring the caller program name to the RFC communication partner | |||||||
A caller program name is now sent to the communication partner when opening a new RFC connection. It can be
retrieved from the RFC attributes at the communication partner side. The caller program name 'SAPJCo30'
is used per default. An arbitrary custom program name can be set by specifying the Java system property
-Djco.program_name=<ProgramName> as a JVM startup parameter.
| |||||||
| Improvement at starting JCoServer instances | |||||||
Starting JCoServer instances has been improved with now doing lazy initializations of RFC repository
destinations and with ignoring and tolerating RFC communication errors at startup.
| |||||||
| Enhancement at runtime initialization with adding a multi-platform library loading feature | |||||||
|
The JCo runtime initialization has been enhanced with a multi-platform library loading feature which allows
to create a central JCo installation that can be started on various operating systems and with using different
Java Virtual Machines without any configuration change. For example, JCo can now be installed on a single
central network share and be used from several operating systems like Windows, Linux or Mac OS X simultaneously.
Or one can work locally with a single JCo installation and use a 32-bit and a 64-bit JVM simultaneously or
choose one or the other JVM alternately at will. For using this feature it is only required to put all desired platform dependent JCo JNI libraries in specifically named subdirectories of the directory where the sapjco3.jar file resides,
e.g. <sapjco3.jar_DIR>\ntamd64\sapjco3.dll , <sapjco3.jar_DIR>\ntintel\sapjco3.dll
or <sapjco3.jar_DIR>/linuxppc64/libsapjco3.so. See the Configuration and Requirements documentation chapter "Runtime initialization" for further details and the list of valid platform specific subdirectoy names. | |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Release notes 3.0.10 | |||||||
| Bugfix for hanging JCoServer connections | |||||||
Under certain circumstances RFC connections to a JCoServer could have get into an unrecoverable
hanging situation. Then RFC requests to a registered JCoServer instance did not return and the
appropriate RFC connection could not be canceled but kept hanging infinitely in any status, even in status
'disconnecting'. Please see SAP note 1791529
for further details.
| |||||||
| Bugfix removing a memory leak in the JCo session management | |||||||
A memory leak was removed within the internal JCo session management. The memory leak occurred after a custom
SessionReferenceProvider implementation had been registered at the JCo runtime environment. Its
method SessionReferenceProvider.isSessionAlive(sessionId) was never called which resulted in
numerous JCo session objects not getting freed although the sessions already had expired.Note: This bug was present in JCo release 3.0.9 only. | |||||||
| Performance bugfix at RFC request dispatching to JCoServers | |||||||
In case of RFC server registrations to some SAP gateway taking a long time for whatever reason (e.g. because the relevant
SAP AS ABAP system or SAP gateway is currently in shutdown or startup phase, the host itself is not reachable via network
or due to network performance issues), the whole RFC request dispatching to all running JCoServer instances
was extremely slow and therefore lead to a performance degradation also of those registered JCo RFC servers and
related SAP AS ABAP systems who actually were not connected to the problematic SAP gateway host.
| |||||||
| Support of extern-to-extern RFC communication | |||||||
|
Support for calling external RFC server programs as well as support for receiving RFC requests from external RFC client
programs has been added. For addressing external RFC server programs the property jco.client.tpname , which specifies the appropriate
registered server program ID, can now be configured for a destination, which then can be used for calling RFC programs
that are registered at a SAP gateway. Additionally, the property jco.destination.repository_destination
should be configured and refer to some destination targeting an appropriate SAP AS ABAP system for retrieving
potentially required RFC meta data.Receiving RFC requests from external RFC client programs is not allowed by default for security reasons. A JCoException with error group JCoException.JCO_ERROR_SYSTEM_FAILURE will be thrown to both
RFC communication partners everytime a JCo RFC server receives such an RFC request. For allowing external RFC client
program calls to be processed by a JCo RFC server an administrator needs to specify the Java system property
as a JVM startup parameter to be already available at JCo
framework initialization time. Please see SAP note 1877907
for further details.Caution: For security reasons SAP discourages to run such extern-to-extern RFC communication scenarios. External or registered RFC server programs are not able to check and authenticate incoming RFC requests from external non-ABAP programs with regard to the pure RFC protocol data. Each of such external RFC requests must be regarded as insecure. | |||||||
| Enhancement with providing support for local repository storages | |||||||
A new feature has been added allowing to save and load a complete JCoRepository instance in JSON format
to and from standard Java I/O character streams.
| |||||||
| Bugfix for StackOverflowError in JCoRepository | |||||||
Depending on the defined DDIC (Data Dictionary) types and structures and on the defined RFM (Remote Function Module)
interfaces at SAP AS ABAP system side a java.lang.StackOverflowError could have been thrown when a
JCoRepository instance was storing the queried RFC meta data into its internal MetaDataStorage
instance.
| |||||||
| Bugfix for avoiding connection interruptions at long running stateful RFC server requests | |||||||
Long running stateful RFC server requests from ABAP to Java were always interrupted after the configured session timeout
interval (default is 10 minutes) without checking at the registered SessionReferenceProvider if the session
would be still alive nevertheless.Note: This bug was present in JCo release 3.0.9 only. | |||||||
| Bugfix in method JCoServerContextInfo.getCallType() | |||||||
Method JCoServerContextInfo.getCallType() always returned null instead of the current type of
the incoming RFC request in form of a JCoServerCallType enumeration object.
| |||||||
| Bugfix in RFC attribute handling when communicating with non-Unicode ABAP systems | |||||||
A java.lang.NullPointerException was always thrown from the internal JCo method getAttributes()
when trying to communicate with a non-Unicode ABAP system that uses an ambiguous blended code page like SAP code page 6110.
| |||||||
| Bugfix for querying structure and record meta data from a JCoRepository in roundtrip optimization mode | |||||||
A JCoRepository instance in roundtrip optimization mode (i.e. the middleware property
jco.use_repository_roundtrip_optimization was set to 1 at its creation time) always returned
null when querying structure or record meta data from an SAP AS ABAP system with methods
JCoRepository.getStructureDefinition(String name) and JCoRepository.getRecordMetaData(String name) .
| |||||||
| Bugfix at getting a repository destination ID | |||||||
Under some special circumstances the method JCo.getRepositoryDestinationID(String destinationID) returned
null indicating that the respective JCoDestination instance for the given destinationID
has not been used for repository queries yet although this is not true.
| |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Deprecated APIs | |||||||
The following APIs have been declared deprecated and will be removed in a future version of JCo:
The APIs have either become obsolete or there is an equivalent substitution available for them. See the API
Documentation for details.
| |||||||
| Release notes 3.0.9 | |||||||
| Bugfix removing a memory leak in the JCoTimeoutChecker thread | |||||||
A memory leak was removed at the internal destination management within the JCoTimeoutChecker thread. This memory
leak was created each time that the registered DestinationDataProvider instance updated or deleted a previously
used destination from its destination configuration repository.Note: This bug was present in JCo release 3.0.8 only. | |||||||
| Bugfix for CPIC communication error "client with wrong appc header version rejected" | |||||||
A program error in the underlying native CPIC communication software layer has been fixed that sometimes led to RFC connections
getting broken. In this case a JCoException with error group JCoException.JCO_ERROR_COMMUNICATION
was thrown and contained the CPIC error message "client with wrong appc header version rejected". Please see SAP note
1664732 for further information.
| |||||||
| Bugfix for RFC callback handling | |||||||
RFC callbacks to the JCo framework were not handled correctly. Although receiving an RFC callback is not an error by itself,
there was always an error of type RfcGetException with message "Received a callback from the communication partner"
logged in the RFC error log file dev_jco_rfc.trc . Despite this log entry, no error or exception was thrown to
the JCo application or signalled to the communication partner. Even if the requested RFC function module was not available
and could not be processed, this was not done and the RFC callback was ignored. If the delta management for RFC table parameters
was active, the erroneous RFC callback handling could furthermore have caused lost table data and table data inconsistencies
between the two communication partners.Now RFC callbacks are handled correctly with throwing a JCoException of error group
JCoException.JCO_ERROR_SYSTEM_FAILURE , if the requested function module is not available, and only in this case
an error is logged to the RFC error log file dev_jco_rfc.trc .
| |||||||
| Bugfix for the middleware property 'jrfc.client_connect_timeout' having no effect | |||||||
RFC logon attempts to an SAP ABAP system have not been interrupted if they were running too long and exceeded the time span
that was specified by the JCo middleware property jrfc.client_connect_timeout (default is 60 seconds). Now a
JCoException with error group JCoException.JCO_ERROR_TIMEOUT will correctly be thrown in such a
situation, thus interrupting the currently running RFC logon attempt.Note: This bug was present from JCo release 3.0.5 to 3.0.8 only. | |||||||
| Bugfix for setting the default or an empty value into fields of type XSTRING | |||||||
After calling method JCoRecord.setValue([name|index], null) or
JCoRecord.setValue([name|index], new byte[0]) for setting the default or an empty field value on fields of
type JCoMetaData.TYPE_XSTRING , the field was not cleared and empty afterwards but contained one 0-byte value,
i.e. a byte array of length 1 (byte[] = { 0x00 } ). This 0-byte value was also sent via RFC to the
communication partner, if the JCoMetaData.TYPE_XSTRING field was part of an importing, changing or tables
parameter in a JCoFunction or a JCoRequest object.
| |||||||
| Bugfix for writing JCo traces when using a JCoServerRequestHandler | |||||||
When using the RFC request/response model at the JCoServer side with a JCoServerRequestHandler
instance processing the incoming RFC requests, JCo neither traced the API calls to the handleRequest(...)
method invocations nor any meta data or content data of these RFC requests, even if the respective JCo trace level was
set for writing such information.
| |||||||
| Improved JCo initialization for recognizing additional Java system properties | |||||||
In addition to setting the properties jco.session_timeout and jco.session_timeout.check_interval
with the method JCo.setProperty(String key, String value) , these two properties can now also be set as Java
system properties with the -D argument when starting the JVM and they will be recognized at JCo initialization.
| |||||||
| Support of user/password logon while using SNC | |||||||
With the new destination logon property jco.client.snc_sso it is possible to turn off the Single Sign On (SSO)
mechanism of SNC by setting it to the value 0 . Thus, it is possible to log on to an SAP ABAP back-end system
with some other user ID not fitting to the SNC identity, while SNC can still be used for encrypting the network
communication. As a prerequisite, a minimum SAP system kernel patch level is required as mentioned in SAP note
1701870.
| |||||||
| Support of logon with external user identification data | |||||||
The destination properties jco.client.extid_type and jco.client.extid_data have been added
for supporting to log on with external user identifaction data to an SAP ABAP back-end system. For this logon variant it is
mandatory to use SNC.
| |||||||
| Improved logon procedure for languages available in Unicode SAP systems only | |||||||
Some languages like Armenian, Georgian, Vietnamese, Macedonian and many others are available in Unicode SAP systems only.
If logging on with such a language to an SAP ABAP back-end system, it was mandatory to specify an additional destination
property like jco.client.codepage with indicating a unicode communication type, otherwise such logons failed
with an JCoException.JCO_ERROR_LOGON_FAILURE showing the error message "Select one of the installed languages"
although the appropriate language was installed.This logon procedure has been improved so that it does not require any additional communication code page destination property anymore in this case. The unicode communication type is now automatically detected and used for logging on with such new SAP system language keys. Please see SAP note 895560 for more details on languages that are only available in Unicode SAP systems. | |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Release notes 3.0.8 | |||||||
| Bugfix removing a memory leak in JCo native JNI layer | |||||||
| A memory leak in the native layer existed when receiving data from the back-end. Thus, more and more native memory was allocated and the process could run out of memory. Please check SAP note 1595477 for details. | |||||||
| Bugfix removing a memory leak in JCoRepository | |||||||
Under certain circumstances, a memory leak was caused by the internal destination management within a repository. This
could have happened when creating many JCoCustomDestination instances from destinations, which did not
have an associated repository yet. In this situation the first call to JCoCustomDestination.getRepository()
on each of such a JCoCustomDestination instance created a memory leak in the Java heap being located in the
returned JCoRepository object.
| |||||||
| Bugfix for connection reset handling against R/3 release 4.6C systems | |||||||
| When communicating with an R/3 release 4.6C system which is running with a 4.6D kernel, the reset of pooled connections was not working as expected. Instead of simply resetting the context in the back-end, the connection was closed and re-established again. In networks with high latency this led to an undesired performance degredation. This was caused by wrongly checking the partner release number instead of the kernel release number. | |||||||
| Bugfix in JCoServer restart mechanism when processing update events | |||||||
| When a server had to be restarted due to a change in the configuration being signaled by an update event, the server did not come up, but was stopped instead. In particular, simply adjusting the trace flag led to this situation. This was caused by the fact, that the new server instance was already started, before the old one had been shutdown completely. | |||||||
| Bugfix for usage of the destination and server data connection property 'gwserv' | |||||||
| If specifying a gateway service with the destination data connection property 'jco.client.gwserv' or with the server data connection property 'jco.server.gwserv', all property string values of format sapgw##s (with # being a placeholder for a digit) were not accepted and an exception was thrown or an error message was logged saying that the gateway service parameter needs to be of a different format. Contrary to this error message, gateway service parameters of format sapgw##s are valid and may be specified alternatively to parameter values of format sapgw## or #### for directly specifying the TCP port number. | |||||||
| Bugfix for JCoCustomDestination instances not getting invalidated | |||||||
A JCoCustomDestination instance was never invalidated and remained usable, even if the destination configuration,
which it is based on, was changed or deleted. Now a JCoException with error group
JCoException.JCO_ERROR_DESTINATION_DATA_INVALID will correctly be thrown, if a JCoCustomDestination
instance will be used in such a situation.
| |||||||
| Bugfix for SSO-Tickets and X.509-Certificates not being used with JCoCustomDestination | |||||||
New SSO-Tickets or X.509-Certificates that are set for a JCoCustomDestination instance were not used, in case
that there was already another SSO-Ticket or X.509-Certificate previously being used for this destination. The previously
set SSO-Ticket or X.509-Certificate was cached and still used instead of the new one. This led to a JCoException
with error group JCoException.JCO_ERROR_LOGON_FAILURE being thrown, if the SSO-Ticket or X.509-Certificate
has been expired in the meantime.
| |||||||
| Bugfix for wrong repository destination being used with JCoCustomDestination | |||||||
After setting a repository destination with method JCoCustomDestination.setRepositoryDestination(JCoDestination) ,
the JCoCustomDestination instance used the passed destination's client connections instead of the desired
repository connections. Depending on the destination configuration this might have led to a wrong repository being
returned on a subsequent call to JCoCustomDestination.getRepository() and/or wrong targeted connections
and logon parameters being used for future meta data queries of the returned JCoRepository instance.
| |||||||
| Improved JCoCustomRepository destination setting | |||||||
The setting of a destination for a JCoCustomRepository instance has been improved. Now it is possible to change
the destination for remote meta data queries with method JCoCustomRepository.setDestination(JCoDestination) .
Before this improvement, it was only allowed to set a destination once and subsequent calls to
JCoCustomRepository.setDestination(JCoDestination) led to a JCoRuntimeException with error group
JCoException.JCO_ERROR_ILLEGAL_STATE being thrown.
| |||||||
| Bugfix at creation of JCoDestinationMonitor objects | |||||||
The method JCoDestination.getMonitor() threw a JCoRuntimeException with error group
JCoException.JCO_ERROR_RESOURCE saying that the destination would not be initialized or would have been already
removed, although this was not true and the JCoDestination instance was actually valid. This error situation
only occurred if the JCoDestination instance's getMonitor() method was called for the first time
and there was no connection pool available for this destination at that time.
| |||||||
| Bugfix in JCoDestinationMonitor returning wrong data | |||||||
JCoDestinationMonitor instances returned wrong data after the connection pool being associated to the monitored
JCoDestination instance was temporarily removed due to inactivity on this destination. In such an error
situation the JCoDestinationMonitor instance always reported that there would not be any open connection and
consequently the number of pooled and used connections would both be 0 . But that potentially did not reflect
the real situation where several new connections for the monitored destination meanwhile might have been opened again.
| |||||||
| New API | |||||||
The following new API has been added and is available for general use:
See the API documentation for details.
| |||||||
| Bugfix for creation of JCoRepository objects | |||||||
The method JCoDestination.getRepository() threw a JCoRuntimeException with error group
JCoException.JCO_ERROR_CONFIGURATION saying that the configuration for this destination would be invalid
in case there was a repository user defined, but no standard user, user alias or logon ticket were configured. Contrary
to this error message, a destination configuration containing only a repository user is sufficient at least for the
creation of and usage by a JCoRepository instance.
| |||||||
| Improved default behavior with connection pooling | |||||||
The default behavior regarding the connection pooling has been improved. If the DestinationDataProvider
does not specify the property jco.destination.pool_capacity for a certain destination, the default value
1 is used for this property now instead of 0 . This means that connection pooling is enabled
by default now and thus dramatically increases the performance of typical single threaded applications who do not care
about connection pooling.
| |||||||
| Release notes 3.0.7 | |||||||
| Support for scope types in the default implementation of the session reference provider | |||||||
|
The default implementation of the SessionReferenceProvider was re-implemented as DefaultSessionReferenceProvider and is now exposed in
com.sap.conn.jco.ext package and supports scopeTypes by default. If an application/infrastructure that uses the default implementation wants
to disable scopeType support again it has to register new DefaultSessionReferenceProvider(false) via the Environment class.
Find more details in the JavaDoc. | |||||||
| Deprecations | |||||||
Some methods in the JCoDestinationManager , the JCoServerFactory , and JCo
have been deprecated. Adjust your coding accordingly so that you don't run into trouble, if those methods are
removed from the public API in future versions of JCo.
| |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Bugfix in SimpleSessionReferenceProvider | |||||||
Under high load, an exception could occur signalling a concurrent modification within an internal HashMap. The exception
callstack could look like as follows:
java.util.ConcurrentModificationException at java.util.HashMap$AbstractMapIterator.checkConcurrentMod() at java.util.HashMap$AbstractMapIterator.makeNext() at java.util.HashMap$KeyIterator.next() at java.util.HashMap.analyzeMap() at java.util.HashMap.rehash() at java.util.HashMap.rehash() at java.util.HashMap.putImpl() at java.util.HashMap.put() at com.sap.conn.jco.rt.SimpleSessionRefProvider.jcoServerSessionPassivated() at com.sap.conn.jco.rt.DefaultServerWorker.callFinishedInternal() ... | |||||||
| Bugfix in JCoRepository with regard to destination handling | |||||||
A repository is shared between several destinations that all establish own connections to the
ABAP system. The destination that is actually used for the lookup causes a JCoException with group
JCoException.JCO_ERROR_LOGON_FAILURE . This exception is thrown due to an incorrect configured repository
user/repository password combination or because the user is locked (e.g. due to running out of the validity period).
Hence, repository queries failed, as repeatedly the "bad" destination is used instead of switching
to the next valid one, which could be used successfully for the query, even though such a mechanism exists in the repository.
Moreover, it could happen that a working back-end user used for metadata lookup is locked after several metadata query tries,
and you will get the message "Password logon no longer possible" when trying to logon with this user.
| |||||||
| Enhancement: special ThreadGroup for Threads created by JCo | |||||||
When JCo is creating Threads internally (e.g. in a JCoServer without a special JCoServerRunnable
implementation or for the Timeoutchecker thread), they are now assigned to a dedicated ThreadGroup belonging to JCo. Thus,
the threads are no longer belonging to random thread groups of the runtime environment, depending on the creation point in
time of the concrete thread.
| |||||||
| Enhancement: DataProviderException | |||||||
| Now, an implementation of DestinationDataProvider and ServerDataProvider may throw a DataProviderException to report an exceptional situation, it encountered while a certain configuration has been requested. | |||||||
| Bugfix in JCoServer setup | |||||||
When using SNC for a JCoServer and using 9 as value for
jco.server.snc_qop , JCo complained wrongly about an invalid value.
This was due to a wrong range usage, when checking the properties: JCo used [0..8] instead of [1..9].
| |||||||
| Bugfix in JCoServer transaction and unit processing setup | |||||||
When there is no JCoServerTIDHandler or no JCoServerUnitIDHandler set for a JCoServer ,
and a tRFC/qRFC or bgRFC unit is received by a server, a NullPointerException without descriptive
message is thrown. If such a handler is missing and a corresponding request shall be processed, JCo now throws a
a JCoRuntimeException with group JCoException.JCO_ERROR_ILLEGAL_STATE that provides a clarifying message.
| |||||||
| Bugfix in JCoServer called by 3.1I ABAP Server | |||||||
| Since JCo 3.0.5, if a 3.1I ABAP System made a request to a JCoServer, it caused an exception with a message similar to RFC_ERROR_SYSTEM_FAILURE: You cannot adjust the state of a ServerConnection with this method. | |||||||
| Bugfix for deployment errors | |||||||
| Sometimes a JCo standalone was deployed accidentally into a NetWeaver AS Java. This could lead to strange error situations that were randomly occuring. Hence, JCo standalone is now denying to be loaded within a NetWeaver AS Java. If JCo should be used within that environment, the embedded JCo variant should be used (can be referred to as tc/bl/jco/api, an application only needs to set this reference in its deployment descriptor). | |||||||
| Bugfix for JCoSessionReferenceProvider server event jcoServerSessionFinished() | |||||||
In a stateless server context, the event method jcoServerSessionFinished() received always null as session ID and not
the expected session ID that was originally provided by the JCoSessionReference returned by jcoServerSessionStarted() .
| |||||||
| Release notes 3.0.6 | |||||||
| Connect failure on load balanced logon under heavy load | |||||||
Caused by a race condition, the JCo runtime could use wrong service if connection was being
established via the message server, that means using load balanced logon. In such cases,
JCo throws an exception with the following error text
LOCATION SAP-Gateway on host | |||||||
| Data element names missing in metadata since JCo 3.0.5 | |||||||
| If in a structure, table or function module a scalar type (e.g. CHAR, NUMC, etc) is refering to a data element, the name of that data element is not returned in getRecordTypeName() in JCo 3.0.5, though this worked fine in JCo 3.0.0 to 3.0.4. | |||||||
| Bugfix in JCoRepository | |||||||
| If a vector of a domain was looked up directly, it did not contain the linetype, hence was not handled like a table type properly. | |||||||
| Bugfix for JCoCustomDestination | |||||||
A JCoDestination is associated with a scopeType via JCoDestinationManager.getDestination(destName, scopeType) .
When now creating a JCoCustomDestination from the retrieved destination, the scopeType
information is ignored, when executing a function module.
| |||||||
| Enhancement for tracing | |||||||
When tracing at high trace levels and large data volumes, the memory footprint of JCo was
increasing stronger than necessary leading to OutOfMemoryErrors too early. Now, the
memory consumption has been reduced and such errors should come up only with even higher data
volumes.
| |||||||
| Enhancement for session timout checking | |||||||
It was impossible to adjust JCo session timeout checking independently from the timeout interval.
This was changed by introducing jco.session_timeout.check_interval that allows specifying a value
in minutes and defaults to 5.
| |||||||
| Roundtrip reduction for repository | |||||||
When JCo is looking up metadata in a back-end for a certain function module, it calls several function modules
providing metadata for the function and the involved structures. In slow networks, e.g. a VPN connection
crossing longer distances, this can lead to bad performance in case of design time scenarios, where the
repository cache is typically not filled and many roundtrips to the back-end are needed.
SAP note 1456826 introduces
RFC_METADATA_GET , with which the number of roundtrips per function is reduced to 1.
JCo now uses this function module, if it's available in the back-end and if the JCo property
jco.use_repository_roundtrip_optimization is set to 1. Please note, that you need
to adjust authorization profiles for your metadata user in that case.
| |||||||
| Bugfix in XRfcParser | |||||||
|
When table type FOO has a table type BAR as line type and one of the rows of FOO contains simply an
empty table BAR, then an expeption occured that looks similar to:
JCO_ERROR_XML_PARSER: Parameter PARAM_FOO: After a value an end tag must follow. That did not
happen in "em> | |||||||
| Bugfix in initialization of RFC parameter defaults | |||||||
RFC function module parameters might not have been initialized correctly when an ABAP system field
(e.g. SY-DATLO or SY-TIMLO ) was defined as its default value. This also
might have led to some ConversionException being thrown when trying to read these
values with the JCoParameterList.getValue() or the various JCoParameterList.get<type>()
methods.
| |||||||
| Bugfix in server registration | |||||||
If a gateway is protected with a reginfo file, a JCoServer is not allowed
to register itself from a certain host and/or a certain program ID with that gateway. Unfortunately, the
JCoServer did not recognize such a registration failure as an unrecoverable configuration error,
and hence tried to re-register again immediately. This was certainly failing again, which was leading to
rapidly growing dev_jco_rfc.trc files.
| |||||||
| Bugfix when degistering DestinationDataProvider | |||||||
When a DestinationDataProvider is deregistered from JCo, the connections established by
destinations created from this provider should be closed. However, this did not work for repository
connections. If afterwards the JCo application is terminated, the ABAP system wrote an
entry containing "SAP-RC=223" into the syslog.
| |||||||
| Bugfixes in server configuration processing | |||||||
When processing changes in server configurations signalled by the ServerDataProvider , not all changes were recognized by the JCoServer .
Even if a change was recognized, and a running server was updated, it was no longer running after that update, but
was simply stopped. In case of restarts, the setting for the maximum restart delay time was ignored.
| |||||||
| Documentation improved | |||||||
Documentation was added and enhanced at different locations, in particular in the cases mentioned below:
| |||||||
| Release notes 3.0.5 | |||||||
| New API and constant | |||||||
The following new API and constant have been added and are available for general use:
See the API documentation for details.
| |||||||
| NullPointerException in Delta Management on ABAP callbacks | |||||||
If an ABAP function module executes a function via destination BACK, a NullPointerException could be thrown
by delta management in JCo. The exception is raised only, if the function module invoked in ABAP has some table parameters.
| |||||||
| Support of multiple repositories for a single JCoServer | |||||||
It is now possible to specify more than one repository for JCoServer and thus be able to
handle requests from various ABAP systems, even if requests base on incompatible function module definitions.
In order to define multiple repositories, JCo introduces a new configuration property: jco.server.repository_map .
Examples how to use it are available in the API documentation of ServerDataProvider .
| |||||||
| Support of dynamic worker thread allocation for JCoServer | |||||||
It is now possible to specify the minimum and maxmimum number of worker threads that shall be used for a JCo Server
via the new server properties jco.server.worker_thread_min_count and jco.server.worker_thread_count.
Mor edetails are available in the API documentation of ServerDataProvider .
| |||||||
| Invalid characters accepted for BCD | |||||||
| When setting a value for a field that is containing a BCD value, and that value contains an invalid character, e.g. an 'a', this value is accepted without error instead of throwing an exception. | |||||||
| Support for cancelling function invocations on session end | |||||||
| When a function module invocation is lasting very long, and as a consequence the session, in which that call was executed, has been finished in the meantime, JCo now requests on the ABAP server that the function module execution shall be cancelled, in order to free resources. | |||||||
| Loss of tRFC requests | |||||||
| When executing multiple tRFCs in parallel threads, some of the tRFCs get lost without any error message. In particular, this can lead to data loss during IDoc communication between a JCo 3.0 based program and the ABAP back-end system. See also note 1438660. | |||||||
| Performance improvement for stateless function module calls | |||||||
| By default, function module invocations are done stateless within JCo 3.0. This means that the context in the ABAP back-end associated with a connection used for a function module invocation is reset after finishing the request. Unfortunately, this is much slower for many small requests than executing stateful due to the existing reset mechanism. With a small improvement within the JCo runtime the reset mechanism could be improved, but requires also an enhancement in the ABAP back-end side. If that enhancement is not available, the behavior will stay like before. Note 1433584 describes which kernel patch level is necessary for the ABAP server. | |||||||
| Release notes 3.0.4 | |||||||
| JCoException with text "Incorrect size of TID encountered [null]" thrown for synchronous client call | |||||||
| If a destination is set to stateful, a qRFC call is executed, and afterwards a synchronous call is executed for the same destination, the JCoException with the message mentioned above is thrown though this should work fine without any problem. | |||||||
| Exception JCO_ERROR_CONFIGURATION on JCoCustomDestination | |||||||
| JCoException with the key JCO_ERROR_CONFIGURATION is thrown on a JCoCustomDestination, if the original JCoDestination it was created from does not contain any user authentication parameters. | |||||||
| Unnecessary refresh on deregistration of DestinationDataProvider | |||||||
| If a DestinationDataProvider is changed or removed, the JCo runtime refreshes the cached destinations. Due to a bug in the refresh operation, the instance of the DestinationDataProvider was used that was just in being deregistered, and not the new one as it should be. | |||||||
| z/OS: ERROR hostname 'abcd' unknown | |||||||
| Even though the technical connection to a certain host was working fine outside JCo, establishing a connection with JCo to an SAP system failed. This was caused by some EBCDIC/ASCII translation issues in a very low level API. See also note 1406061. | |||||||
| Release notes 3.0.3 | |||||||
| Support for dealing with bgRFC units | |||||||
It is now possible to interact with SAP AS ABAP back-ends supporting the successor of tRFC and qRFC
completely in native bgRFC mode, both for client and server applications. Certainly, the back-end release
has to support bgRFC as well. For details check out the API documentation of the interfaces and enums below:
| |||||||
| Support for ABAP class exceptions | |||||||
Starting with ABAP application server release 7.11 it is possible to use function modules throwing an
abap class exception between two ABAP systems. With 7.20 the support was extended to connectors as well,
including JCo 3.0. Hence, more context of the application in the ABAP system can be transferred in
such an exception object, which makes it easier to find causes of undesired behavior of the application.
For details check out the API documentation of the classes and interfaces below:
| |||||||
| Changing parameters are not updated | |||||||
| When a function module had a changing parameter, and the application did not set any value to it, before invoking function module in the back-end, the updates to it in the back-end were not received by the Java application. | |||||||
| StackOverflowError in MetaDataStorage | |||||||
Under certain circumstances it could occur when some metadata object is stored in a
repository's data store. The call stack of the error included the following sequence very often:
at com.sap.conn.jco.rt.MetaDataStorage.updateParents() at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData() at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData() at com.sap.conn.jco.rt.MetaDataStorage.saveFunctionTemplate() at com.sap.conn.jco.rt.MetaDataStorage.updateParents() at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData() at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData() at com.sap.conn.jco.rt.MetaDataStorage.saveFunctionTemplate() at com.sap.conn.jco.rt.MetaDataStorage.updateParents() at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData() at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData() ... | |||||||
| JCo cuts off the last field of a structure or table row | |||||||
| See also note 1358698. If a table or strufture definition was extended compatibly between two releases by simply extending the last field, e.g. by extending a CHAR 5 field to CHAR 10, and JCo was only aware of the shorter version of the metadata, but the longer one was sent to JCo, the value of that field was simply not stored, and the field remained initial. In particular, this occurred as well, if there was only a single field in the structure or table row. | |||||||
| Exception text was not sent to caller | |||||||
When an implementation of a JCoServerTIDHandler threw an exception within checkTID, the text was
not sent to the caller.
| |||||||
| NullPointerException in JCoServer | |||||||
When a JCoServer was started twice, because of some minor changes, and was not stopped properly before,
and the ServerDataProvider did not support events, this could lead to a NullPointerException, when a
new request for this server was coming in.
| |||||||
| Release notes 3.0.2 | |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Bugfix for hanging JCoServer if connections were set to stateful | |||||||
See also note 1298438.
When setting its connections to stateful, a JCoServer could hang completely when the gateway on which the server has been registered is
sending a ping to the server connection because the ABAP client has not been sending requests for a while. The JCoServer connection then
ends up in a call stack for server threads in a thread dump that looks similar to the following one:
"sap.rfc.Listener SAPBC <IP_ADDRESS>" cpu=136953.28 [reset 136953.28] ms allocated=30367383456 B (28.28 GB) [reset<PHONE_NUMBER>6 B (28.28 GB)] prio=6 tid=0x0000000015328b50 nid=0x1960 runnable [0x000000001922f000..0x000000001922f7d0] java.lang.Thread.State: RUNNABLE at com.sap.conn.rfc.driver.CpicDriver.nativeCpic_coxread([BI[B[I)I(Native Method) at com.sap.conn.rfc.driver.CpicDriver.cpic_coxread(I[B[I)I(CpicDriver.java:692) at com.sap.conn.rfc.driver.RfcTypeRegisterCpic.listen([BI[II)I(RfcTypeRegisterCpic.java:70) - locked <0x000000018b411e68> (a com.sap.conn.rfc.driver.RfcTypeRegisterCpic) at com.sap.conn.rfc.engine.RfcIoOpenCntl.ab_rfclisten(I)I(RfcIoOpenCntl.java:1293) at com.sap.conn.rfc.engine.RfcIoOpenCntl.RfcListen(I)I(RfcIoOpenCntl.java:2194) at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(LServerWorker;)V(MiddlewareJavaRfc.java:2060) at com.sap.conn.jco.rt.DefaultServerWorker.dispatch()V(DefaultServerWorker.java:259) at com.sap.conn.jco.rt.DefaultServerWorker.loop()V(DefaultServerWorker.java:321) at com.sap.conn.jco.rt.DefaultServerWorker.run()V(DefaultServerWorker.java:220) at com.wm.util.TimeWrappingProvider$TimeMesuredTask.run()V(TimeWrappingProvider.java:40) at com.wm.pkg.sap.rfc.ListenerThread.run()V(ListenerThread.java:70) - locked <0x000000017757a778> (a java.lang.Thread for sap.rfc.Listener BCSAPPRD <IP_ADDRESS>) | |||||||
| Bugfix in treatment of one-digit BCD value | |||||||
| BCD fields were filled incorrectly if a one-digit value was set (e.g. 4 or 7). The resulting value was always 0 (or 0.0 - with n 0 after the dot if the number of decimals is n in the metadata definition). | |||||||
| Bugfix for exception group in case of wrong credentials | |||||||
Error group JCO_ERROR_CANCELLED was used instead of JCO_ERROR_LOGON_FAILURE , moreover the error message was misleading.
| |||||||
| Bugfixes in session context handling | |||||||
| |||||||
| Bugfix for plain-text password in trace | |||||||
|
The trace file could contain a trace entry, in which you find the string
'jco.destination.repository.passwd=' followed by the password for the repository user, i.e. the user with which
metadata information is queried in the SAP system. See also security note 1312880 | |||||||
| Bugfix for stateful JCoServer connections | |||||||
| Stateful server connections could not be set to stateless again. | |||||||
| Bugfix for session events triggered by JCoServer connections | |||||||
The events for sessions started by a JCoServer could be triggered more often than necessary. In particular, this was
true for the jcoServerSessionStarted() event, for which then there did not exist a corresponding jcoServerSessionFinished()
event. As a consequence too many idling sessions were created in the runtime environment.
| |||||||
| Bugfix for JCoServerMonitor information | |||||||
Under very high load both getUsedServerThreadCount() and getMaximumUsedServerThreadCount() were increasing above
the configured maximum until the load was lower again and then remained at the wrong high level.
| |||||||
| Bugfix in numeric handling of signed or empty field values | |||||||
A ConversionException was thrown when trying to get an empty or signed value
from a field of type CHAR as a converted numeric value. The following JCoRecord
methods were affected: getInt() , getShort() , getLong() ,
getBigInteger() , getDouble() , getFloat() and getBigDecimal() .
| |||||||
| Bugfix in repository for nested vector types | |||||||
| Table types that referred to a table type as line type which itself refers again to a table type as line type and table types that referred to a table type as line type which referse to a domain as line type were not correctly stored in the repository, when being looked up from an ABAP system. As a consequence function modules that had parameters of such a type could not be processed correctly. | |||||||
| Bugfix for java.lang.UnsatisfiedLinkError | |||||||
A java.lang.UnsatisfiedLinkError occurred with the message com.sap.i18n.cp.ConverterJNI.ConvertCToXArrR([B[CII[BII[I)I , when a blended
codepage such as 6100 is used.
| |||||||
| Bugfix for starting SAP GUI on Unix and MacOS | |||||||
| If the path to the SAP GUI contained blanks, starting the Java GUI failed. On MacOS, in addition some startup parameters needed to be adopted. | |||||||
| Bugfix for tables in changing parameter lists | |||||||
| If a table was part of the changing parameter list, and was not containing any row when executing the function module, then the table was always returned empty. | |||||||
| Enhancement for destination and server configuration management | |||||||
| If a configuration was updated, and someone uses a cached instance of a JCoServer or JCoDestination, an exception will be thrown to signal that this instance is outdated. | |||||||
| Release notes 3.0.1 | |||||||
| Improved documentation | |||||||
|
An example for a CustomDestinationDataProvider has been added.
API documentation has been extended and improved. | |||||||
| New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API documentation for details.
| |||||||
| Support for SAP GUI | |||||||
JCo is now able to start a SAP GUI on the local machine and associate it with a newly opened RFC connection.
The back-end prerequisites for this new feature are listed in note
1258724. Starting the SAP GUI can be controlled
by the additional destination parameter jco.client.use_sapgui .
| |||||||
| Bugfix in dispatcher worker thread | |||||||
The dispatcher worker thread might have been finished after errors occurring under heavy load. The thread dump
does not contain a thread called JCoDispatcherWorkerThread in this case.
The dispatcher worker thread might be started more than once due to insufficient synchronization. The thread dump contains more than one thread called JCoDispatcherWorkerThread in this case.
| |||||||
| Bugfix for functions containing more than 127 non-scalar parameters | |||||||
Functions with more than 127 non-scalar parameters caused an ArrayIndexOfBoundsException . The fix required a change for the
serial version UID of many data containers and metadata instances so that serialized instances of these classes can no longer be exchanged
with previous releases.
| |||||||
| Bugfix for ArrayIndexOutOfBoundsException on receive | |||||||
ArrayIndexOutOfBoundsExceptions might be thrown while receiving data (output parameters in client scenario or
input parameters in server scenario). The exception is thrown if the ABAP side has extended the data strcutures used
by the current function module compared to JCo's own metadata definition.
| |||||||
| Bugfix for JCO_ERROR_DSR_PASSPORT_NOT_RECEIVED | |||||||
A JCoException with the key JCO_ERROR_DSR_PASSPORT_NOT_RECEIVED was thrown in a JCo server on second
and subsequent stateful requests.
| |||||||
| Bugfix in treatment of default BCD value | |||||||
| BCD fields were filled incorrectly if the default values was set. On the ABAP side the incorrect content of the BCD field caused short dumps (ABAP runtime error BCD_BADDATA). | |||||||
| Bugfix in firing of server events | |||||||
The event ALIVE was not fired by the JCo runtime, if the ABAP system/gateway hase gone online when
the server was in the state DEAD . That might cause that the server application remained in the
the waiting state.
| |||||||
| Bugfix for native crash during stateful server communication | |||||||
A native crash occurred on stateful requests from ABAP to Java
| |||||||
| Bugfix for server connection leak | |||||||
The JCo server did not release the internal connection handle properly, if the gateway was protected
with an ACL and the connection was declined. After a while all internal handles were used and either an ArrayIndexOutOfBoundsException: 10000 was thrown and
logged to dev_jco_rfc.trc each time a new connection was required. This is the same issue as described in note 1252962. | |||||||
|
|
|||||||
| Copyright © 2008-2016 SAP SE. All Rights Reserved. |


Installation
Shared Hosting :
-
CPanel and FTP
You need to have CPANEL and FTP access to install on shared hosting . Create a new FTP account or if you have existing download filezilla config file , install Filezilla and import new config and connect to server using filezilla , now upload all files into your website folder and open cpanel
-
Permissions
Now open filezilla and give recursive 775 permissions to .env , storage , bootstrap and public/uploads folder , Make sure to click recursive when you set permissions
-
Database
After opening cpanel go to mysql databases and create new database , then create new user , then from mysql databases screen connect user and database and grant all permissions . Now visit /install on your server and continue installation
-
Check your PHP version
You will need to have PHP version 5.5 or above , so check it with your hosting provider , Some hosting providers allow to change version from cpanel so select 'Select PHP Version' from CPANEL and set it to 5.5 or above
Cloud Hosting (DigitalOcean) :
-
Create a new droplet and upload files
Click on create new droplet and select LAMP from applications tab , now upload all files to your droplets folder (/var/www/html) through filezilla
-
Connect to droplet through SSH (Putty)
Now connect to droplet through putty and run below commands
chgrp -R www-data /var/www/html
chmod -R 775 /var/www/html/.env
chmod -R 775 /var/www/html/storage
chmod -R 775 /var/www/html/bootstrap
chmod -R 775 /var/www/html/public/uploads
-
Database
When you connect to droplet through Putty you will see a message on top which will include mysql password , so now lets connect to mysql and create database and dump demo sql
mysql -u root -p;
create database rss;
-
Enable Modules
Run below command to enable mod_rewrite module
Now open 000-default.confsudo a2enmod rewrite
Add below lines belowsudo nano /etc/apache2/sites-available/000-default.conf
Now restart apache2 server<Directory "/var/www/html"> AllowOverride all </Directory>
sudo service apache2 restart
- Visit /install on your server and continue installation
Admin Features
-
Built on Laravel Framework
Laravel is one of the most popular framework at the moment and is full of features. It is easy to use and it offers a large variety of packages using composer . -
Add users
You can add , edit and delete the administrators -
Categories and Sub Categories
You can create categories and sub categories , sometimes all categories do not fit in header you have the option to display categories in header , sidebar and footer and can even hide from each place . You can also set seo keywords and description for each category / sub category -
Sources
You can connect source to any sub category and all rss feeds will be pulled and saved in our database , You can even setup cron job to automatically pull new posts from sources every X hrs , you even have a option to preview source before adding to sub category -
Posts
In this section all posts which are manual or connected to any source will be displayed. If you dont want to display post set its status to INVISIBLE . -
Ads Section
We have added every possible ad section a user will ever want . On homepage you can add ads on the top or in the bottom , You can add ads in sidebar , You can add ads between pages like tags , search , categories or sub categories , can even add ads on top or bottom of each posts -
Statistics / Google Analytics
Now you dont need go to google analytics to check basics stats , you can add your app client id inside .env file and analytics will be available for you in this section -
Settings
We have tons of configuration here , you can control site wide settings . You can set site url , title , upload logos , set google analytics , mailchimp form , should sources be included in rss feeds if site generate feeds , Google/Bing webmaster verify , can select type of commenting system to use , set facebook box , set twitter box , set social links of header and lot of other options
Site Features
-
User Friendly
Smooth and sleek design and understandable to user -
Post a Job
Users can add jobs from the frontend . -
Find a Job
Users can find jobs by using filters or advanced search integrated . -
Authentication
High security only authentic users can access the platform. -
Registration
Users can register them from frontend in order to post job and save resume. -
My Account
Shows list of jobs posted by the specific user. -
Upload Resume
A user can upload resume in order to apply multiple jobs. -
20+ Ads Sections
You have 20+ ads sections for settings ads and earning through your website -
SEO Friendly
All proper meta tags are used for seo and can be easily set from settings panel
Setting Cron Job
For sources to auto update you need to set cron job on server , so SSH into server and run below commands
sudo crontab -e
Now add one of the below line at the end of file as per your choice
* * * * * /usr/bin/php /var/www/html/crons/update-sources.php
for running cron job every minute
0 * * * * /usr/bin/php /var/www/html/crons/update-sources.php
for running cron job every hour
Make sure to replace the php path and your web root path in above commands
Setting up Mail
SMTP METHOD :
You just have to change settings inside .env to make smtp work
MAILGUN :
Set mail settings in .env
and set mailgun domain and secret inside
config/services.php
Changing Language
To change language go to resources/lang and clone 'en' directory and rename to your two digit language code click here for language codes
After above step go to .env file and set the two digit locale code for LOCALE
Now you can edit your language in new directory in resources/lang
Installing Updates
To install updates just replace all folders except uploads on your server and follow below steps , also check your language files after update for new messages .
After uploading new files make sure
-
If you have SSH Access
If you have SSH access then ssh to your project directory and set 775 permission to below folderschgrp -R www-data /var/www/html
chmod -R 775 /var/www/html/.env
chmod -R 775 /var/www/html/storage
chmod -R 775 /var/www/html/bootstrap
chmod -R 775 /var/www/html/public/uploads
Now visit /install on your server to continue upgrade
-
For No SSH Access
If you dont have access to SSH then ftp into your project through filezilla and set 775 permissions to storage and bootstrap (You can set permissions by right clicking the folder and selecting file permissions and make sure to check the box which says Recurse into sub directories) . Now visit /install on your server to continue upgrade
Source and Credits
I've used the following frameworks, fonts, icons and scripts as listed. My thanks goes to all the authors!
| Frameworks |
|---|
| Laravel |
| Scripts and Plugins |
|---|
| Jquery |
| JqueryUI |
| Tags |
| Boostrap Datepicker |
| Jquery Form |


Whether you are new in town or a local - discover events near you that you would love
Can't find what you are looking for? Create an event or activity and decide what you want to do, when you want to do it and whom you want to do it with
Let people know what activities can take place in your space Maybe a game night, paintballing, hiking, yoga or something completely new


Class Call
Inheritance
System.Object
Call
Implements
System.ComponentModel.INotifyPropertyChanging
System.ComponentModel.INotifyPropertyChanged
Inherited Members
System.Object.ToString()
System.Object.Equals(System.Object)
System.Object.Equals(System.Object, System.Object)
System.Object.ReferenceEquals(System.Object, System.Object)
System.Object.GetHashCode()
System.Object.GetType()
System.Object.MemberwiseClone()
Assembly: BatRecordingManager.dll
Syntax
[Table(Name = "dbo.Call")]
public class Call : INotifyPropertyChanging, INotifyPropertyChanged
Constructors
|
Improve this Doc
View Source
Call()
Declaration
Properties
|
Improve this Doc
View Source
BatCalls
Declaration
[Association(Name = "Call_BatCall", Storage = "_BatCalls", ThisKey = "Id", OtherKey = "CallID")]
public EntitySet<BatCall> BatCalls { get; set; }
Property Value
| Type |
Description |
| System.Data.Linq.EntitySet<BatCall> |
|
|
Improve this Doc
View Source
CallFunction
Declaration
[Column(Storage = "_CallFunction", DbType = "VarChar(50)")]
public string CallFunction { get; set; }
Property Value
| Type |
Description |
| System.String |
|
|
Improve this Doc
View Source
CallNotes
Declaration
[Column(Storage = "_CallNotes", DbType = "VarChar(MAX)")]
public string CallNotes { get; set; }
Property Value
| Type |
Description |
| System.String |
|
|
Improve this Doc
View Source
CallPictures
Declaration
[Association(Name = "Call_CallPicture", Storage = "_CallPictures", ThisKey = "Id", OtherKey = "CallID")]
public EntitySet<CallPicture> CallPictures { get; set; }
Property Value
| Type |
Description |
| System.Data.Linq.EntitySet<CallPicture> |
|
|
Improve this Doc
View Source
CallType
Declaration
[Column(Storage = "_CallType", DbType = "VarChar(50)")]
public string CallType { get; set; }
Property Value
| Type |
Description |
| System.String |
|
|
Improve this Doc
View Source
EndFrequency
Declaration
[Column(Storage = "_EndFrequency", DbType = "Float")]
public double? EndFrequency { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
EndFrequencyVariation
Declaration
[Column(Storage = "_EndFrequencyVariation", DbType = "Float")]
public double? EndFrequencyVariation { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
Id
Declaration
[Column(Storage = "_Id", AutoSync = AutoSync.OnInsert, DbType = "Int NOT NULL IDENTITY", IsPrimaryKey = true, IsDbGenerated = true)]
public int Id { get; set; }
Property Value
| Type |
Description |
| System.Int32 |
|
|
Improve this Doc
View Source
PeakFrequency
Declaration
[Column(Storage = "_PeakFrequency", DbType = "Float")]
public double? PeakFrequency { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
PeakFrequencyVariation
Declaration
[Column(Storage = "_PeakFrequencyVariation", DbType = "Float")]
public double? PeakFrequencyVariation { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
PulseDuration
Declaration
[Column(Storage = "_PulseDuration", DbType = "Float")]
public double? PulseDuration { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
PulseDurationVariation
Declaration
[Column(Storage = "_PulseDurationVariation", DbType = "Float")]
public double? PulseDurationVariation { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
PulseInterval
Declaration
[Column(Storage = "_PulseInterval", DbType = "Float")]
public double? PulseInterval { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
PulseIntervalVariation
Declaration
[Column(Storage = "_PulseIntervalVariation", DbType = "Float")]
public double? PulseIntervalVariation { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
SegmentCalls
Declaration
[Association(Name = "Call_SegmentCall", Storage = "_SegmentCalls", ThisKey = "Id", OtherKey = "CallID")]
public EntitySet<SegmentCall> SegmentCalls { get; set; }
Property Value
| Type |
Description |
| System.Data.Linq.EntitySet<SegmentCall> |
|
|
Improve this Doc
View Source
StartFrequency
Declaration
[Column(Storage = "_StartFrequency", DbType = "Float")]
public double? StartFrequency { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
|
Improve this Doc
View Source
StartFrequencyVariation
Declaration
[Column(Storage = "_StartFrequencyVariation", DbType = "Float")]
public double? StartFrequencyVariation { get; set; }
Property Value
| Type |
Description |
| System.Nullable<System.Double> |
|
Methods
|
Improve this Doc
View Source
SendPropertyChanged(String)
Declaration
protected virtual void SendPropertyChanged(string propertyName)
Parameters
| Type |
Name |
Description |
| System.String |
propertyName |
|
|
Improve this Doc
View Source
SendPropertyChanging()
Declaration
protected virtual void SendPropertyChanging()
Events
|
Improve this Doc
View Source
PropertyChanged
Declaration
public event PropertyChangedEventHandler PropertyChanged
Event Type
| Type |
Description |
| System.ComponentModel.PropertyChangedEventHandler |
|
|
Improve this Doc
View Source
PropertyChanging
Declaration
public event PropertyChangingEventHandler PropertyChanging
Event Type
| Type |
Description |
| System.ComponentModel.PropertyChangingEventHandler |
|
Implements
System.ComponentModel.INotifyPropertyChanging
System.ComponentModel.INotifyPropertyChanged
Extension Methods


- New: Black Ops 4 support in Battle.net plugin
- New: Automatic import of Half-Life 1 and 2 mods (by psychonic)
- New: TGA image support for game metadata
- New: Removed unnecessary system information from diagnostics package
- New: Option to update specific library on demand
- New: Option to start Playnite minimized
- New: Option to run Playnite when computer starts
- New: Option to disable metadata download after game import
- New: Option to disable background image
- New: Installation no longer requires admin privileges
- New: Diagnostics package is automatically uploaded after it's generated
- Fix: Play time of some Origin games not being counted properly
- Fix: Game edit window polish
- Fix: Game deselected after assigning categories
- Fix: Failed load of script extension prevents Playnite from starting properly
- Fix: Description paragraphs not rendered correctly
- Fix: Database import from previous playnite version fails
- Fix: Copied emulator profiles cannot be used
- Fix: Battle.net games are not automatically starter if Battle.net is not already running


Element index for package Model
[ a ]
[ b ]
[ c ]
[ d ]
[ e ]
[ f ]
[ g ]
[ h ]
[ i ]
[ j ]
[ k ]
[ l ]
[ m ]
[ n ]
[ o ]
[ p ]
[ q ]
[ r ]
[ s ]
[ u ]
[ v ]
[ w ]
[ _ ]
_
- _init
- in file Model.php, method Model::_init()
- __call
- in file Model.php, method Model::__call()
- __construct
- in file Model.php, method Model::__construct()
- _init
- in file PDOEngine.php, method PDOEngine::_init()
Method: _init Constructor.
- _init
- in file MySQLEngine.php, method MySQLEngine::_init()
Method: _init Constructor.
- _init
- in file MongoDbEngine.php, method MongoDbEngine::_init()
- __call
- in file PDOEngine.php, method PDOEngine::__call()
Method: __call Redirects all calls to this class to the PDO class
- __construct
- in file Collection.php, method Collection::__construct()
- __destruct
- in file MongoDbEngine.php, method MongoDbEngine::__destruct()
- __get
- in file Collection.php, method Collection::__get()
- __get
- in file MongoDbEngine.php, method MongoDbEngine::__get()
- __toString
- in file Collection.php, method Collection::__toString()
- _add
- in file Query.php, function _add()
Method: _add
- _assemble
- in file Query.php, function _assemble()
Method: _assemble Assables the Query
- _assembleDelete
- in file Query.php, function _assembleDelete()
Method: _assembleDelete Assebles a DELETE query
- _assembleInsert
- in file Query.php, function _assembleInsert()
Method: _assembleInsert Assembles a INSERT Query
- _assembleSelect
- in file Query.php, function _assembleSelect()
Method: _assembleSelect Assables a SELECT query
- _assembleUpdate
- in file Query.php, function _assembleUpdate()
Method: _assembleUpdate Assembales a UPDATE query
- _endQuery
- in file Query.php, function _endQuery()
Method: _endQuery
- _join
- in file Query.php, function _join()
Method: _join Prepares Joins
- _startQuery
- in file Query.php, function _startQuery()
Method: _startQuery
- _toArray
- in file ResultSet.php, method ResultSet::_toArray()
Method: _toArray
- _toString
- in file Query.php, function _toString()
Method: _toString Returns the Query
- _type
- in file Query.php, function _type()
Method: _type Returns the Querytype
- __construct
- in file SingleResult.php, method SingleResult::__construct()
Method: __construct
- __construct
- in file Query.php, method Query::__construct()
Method: __construct Sets the Adapter and the table name.
- __construct
- in file ResultSet.php, method ResultSet::__construct()
Method: __construct
- __get
- in file ResultSet.php, method ResultSet::__get()
top
top
b
- bind
- in file Query.php, function bind()
Method: bind
top
top
d
- delete
- in file Query.php, function delete()
Method: delete Initilizes a DELETE query
- distinct
- in file Query.php, function distinct()
Method: distinct Adds the Distinct clause to the SELECT query
top
e
- EngineNotFoundException
- in file EngineNotFoundException.php, class EngineNotFoundException
EngineNotFoundException.php
- EngineNotFoundException.php
- procedural page EngineNotFoundException.php
- escpae
- in file Query.php, function escpae()
Method: escpae Escapes a Value for use in the query
- exec
- in file Query.php, function exec()
Method: exec Executes the Query.
top
f
- fetch
- in file Query.php, function fetch()
Method: fetch
- fetchAll
- in file Query.php, function fetchAll()
Method: fetch Executes the query and returns a Resultobject containg all results
- from
- in file Query.php, function from()
Method: from Adds the FROM clause to the query
- fulljoin
- in file Query.php, function fulljoin()
top
g
- getInstance
- in file InterfaceEngine.php, function getInstance()
- getQuery
- in file ResultSet.php, method ResultSet::getQuery()
Method: getQuery
- getTime
- in file ResultSet.php, method ResultSet::getTime()
Method: getTime
- group
- in file Query.php, function group()
Method: group Adds the GROUP BY Clause to the query
top
h
- having
- in file Query.php, function having()
Method: having Adds the having clause to the array.
top
top
j
- join
- in file Query.php, function join()
Method: join
top
top
l
- leftjoin
- in file Query.php, function leftjoin()
- limit
- in file Query.php, function limit()
Method: limit Adds the LIMIT clause to the Query
top
m
- Model
- in file Model.php, class Model
Model.php - dioxid
- Model.php
- procedural page Model.php
- MongoDbEngine
- in file MongoDbEngine.php, class MongoDbEngine
MongoDbEngine.php
- MySQLEngine
- in file MySQLEngine.php, class MySQLEngine
dioxid\model\engine$MySQLEngine Baseclass for MySQL Models.
- MongoDbEngine.php
- procedural page MongoDbEngine.php
- MySQLEngine.php
- procedural page MySQLEngine.php
top
top
o
- order
- in file Query.php, function order()
Method: order Adds the ORDER BY Clause to the query
- orWhere
- in file Query.php, function orWhere()
Method: orWhere Adds an Where clause to the query
top
p
- PDOEngine
- in file PDOEngine.php, class PDOEngine
dioxid\model\engine$PDOEngine Abstract Baseclass for PDO related models.
- PDOEngine.php
- procedural page PDOEngine.php
top
q
- query
- in file Model.php, method Model::query()
- query
- in file Collection.php, method Collection::query()
- Query
- in file Query.php, class Query
dioxid\model\query$Query
- querytime
- in file Query.php, function querytime()
Method: querytime Calculates the time the query needed
- Query.php
- procedural page Query.php
top
top
s
- select
- in file Query.php, method Query::select()
Method: select Initalizes a Select query.
- SingleResult
- in file SingleResult.php, class SingleResult
SingleResult.php
- SingleResult.php
- procedural page SingleResult.php
top
u
- union
- in file Query.php, function union()
Method: union Adds an UNION to the query
- update
- in file Query.php, method Query::update()
Method: update Initializes a UPDATE Query.
top
top
w
- where
- in file Query.php, function where()
Method: where Adds a Where clause to the query
top
|
|


Can't Stop Columbus is a community-wide movement that addresses problems that have arisen due to the COVID-19 crisis. Activating our city's talents and passions, we're putting bold ideas into action to deliver real solutions that unite our community.
We envision a city that not only survives the challenges created by this global pandemic, but emerges stronger and more resilient. Stronger because the solutions delivered by Can’t Stop Columbus have made a difference in the lives of those most impacted by COVID-19. More resilient because CSC has created a model for a more targeted and efficient approach to delivering solutions to our community’s most urgent needs by tapping into our city’s deep pool of talented, highly-skilled and community-minded professionals.


这个是简单二叉树的模拟，不需要真正建立二叉树，只需要按照先序模拟二叉树的建立即可。
| The Falling Leaves |
Each year, fall in the North Central region is accompanied by
the brilliant colors of the leaves on the trees, followed quickly
by the falling leaves accumulating under the trees. If the same
thing happened to binary trees, how large would the piles of leaves
become?
We assume each node in a binary tree “drops” a number of leaves
equal to the integer value stored in that node. We also assume that
these leaves drop vertically to the ground (thankfully, there’s no
wind to blow them around). Finally, we assume that the nodes are
positioned horizontally in such a manner that the left and right
children of a node are exactly one unit to the left and one unit to
the right, respectively, of their parent. Consider the following
tree:
The nodes containing 5 and 6 have the same horizontal position
(with different vertical positions, of course). The node containing
7 is one unit to the left of those containing 5 and 6, and the node
containing 3 is one unit to their right. When the “leaves” drop
from these nodes, three piles are created: the leftmost one
contains 7 leaves (from the leftmost node), the next contains 11
(from the nodes containing 5 and 6), and the rightmost pile
contains 3. (While it is true that only leaf nodes in a tree would
logically have leaves, we ignore that in this problem.)
Input
The input contains multiple test cases, each describing a single
tree. A tree is specified by giving the value in the root node,
followed by the description of the left subtree, and then the
description of the right subtree. If a subtree is empty, the value
-1 is supplied. Thus the tree shown above is specified as
5 7 -1 6 -1 -1 3 -1 -1. Each actual tree node contains a
positive, non-zero value. The last test case is followed by a
single -1 (which would otherwise represent an empty tree).
Output
For each test case, display the case number (they are numbered
sequentially, starting with 1) on a line by itself. On the next
line display the number of “leaves” in each pile, from left to
right, with a single space separating each value. This display must
start in column 1, and will not exceed the width of an 80-character
line. Follow the output for each case by a blank line. This format
is illustrated in the examples below.
Sample
Input
5 7 -1 6 -1 -1 3 -1 -1
8 2 9 -1 -1 6 5 -1 -1 12 -1
-1 3 7 -1 -1 -1
-1
Sample
Output
Case 1: 7 11 3
Case 2: 9 7 21 15
代码：
#include<iostream>
#include<fstream>
#include<cstring>
#define maxn 100000
#define middle 50000
using namespace std;
int number[maxn];
int len;
void buildtree(int num,int a){
if(num==-1){
return ;
}
if(number[a]==0)len++;
number[a]+=num;
cin>>num;
buildtree(num,a-1);
cin>>num;
buildtree(num,a+1);
}
int main()
{
// freopen("test.txt","r",stdin);
int num;
int count=0;
while(cin>>num&&num!=-1){
count++;
len=0;
memset(number,0,sizeof(number));
buildtree(num,middle);
cout<<"Case "<<count<<":"<<endl;
int begin=middle;
while(number[begin]){
begin--;
}
begin++;
for(int i=begin;i<len+begin;i++){
cout<<number[i];
if(i!=begin+len-1)cout<<" ";
else cout<<endl;
}
cout<<endl;
}
return 0;
}


Joe Gomez 'better than good' after Raheem Sterling clash, says Jurgen Klopp
Liverpool defender Joe Gomez is "better than good" after a clash with England team-mate Raheem Sterling on international duty, says Jurgen Klopp.
Manchester City forward Sterling was dropped for the Euro 2020 qualifier against Montenegro on 14 November after "a disturbance in a private team area".
But he returned for the qualifier in Kosovo three days later.
"The people involved were fine pretty quick. Things like this happen in football," Liverpool boss Klopp said.
"The FA dealt with it; I can't judge that. The players are absolutely OK."
Sterling and Gomez had been involved in an on-field argument during Liverpool's 3-1 Premier League victory over City at Anfield on 10 November, just before the international break.
City, fourth in the Premier League, are eight points behind leaders Liverpool, who can extend that advantage with a win at Crystal Palace on Saturday (15:00 GMT).
Sterling, who admitted "emotions got the better of me" and apologised to Gomez and the rest of the England squad, is expected to play for City at home to Chelsea later in the day (17:30).
City manager Pep Guardiola said: "We are good. I spoke with him and he's fine. He's an excellent guy.
"He says Joe is an excellent guy and they have a good relationship."